- 16-10 Apollo is wederom om onduidelijke redenen onderuit gegaan en wil niet meer tot leven komen. Gelegenheidsmonteurs Floris en Marcel zijn inmiddels in Telecity aanwezig en hebben Apollo voorzien van een nieuw Tyan Tiger moederbord. Dit heeft Apollo echter nog niet volledig kunnen reanimeren. Het forum blijft dus nog even onbereikbaar. Van de gelegenheid wordt meteen gebruik gemaakt om webserver Argus te voorzien van twee nieuwe AMD Athlon MP 1900+ processors, ter vervanging van de oude MP 1200 exemplaren. Een defect aan één van deze processors was waarschijnlijk verantwoordelijk voor de instabiliteit van Argus.
- 15-10 Apollo, de databaseserver voor het forum, is zo rond 19:45 uitgevallen. Na enkele vruchteloze pogingen om hem op afstand weer tot leven te wekken is Daniel
op zijn fietsin zijn auto gestapt om Apollo handmatig door de bootprocedure heen te helpen. Tegelijkertijd is Argus ook weer aangezet. Deze zal binnenkort voorzien worden van nieuwe Athlon MP processors waarmee we de stabiliteitsproblemen hopen op te lossen. - 8-10 De Net.App die op dit moment als fileserver fungeert heeft last van een herfstdepressie waardoor zowel de frontpage als het forum soms enige minuten onbereikbaar kunnen zijn. Dat is namelijk precies de tijd die de Net.App nodig heeft om zichzelf weer up te helpen. Waardoor dit wordt veroorzaakt en wat de oplossing is op dit moment nog onduidelijk. Onze excuses voor het ongemak.
- 15-09 In verband met updates van de software zal de Tweakers.net frontpage rond middennacht enige tijd ontoegankelijk zijn. Het forum zal wel bereikbaar blijven.
- 10-09 Argus is vanwege zijn aanhoudende stabiliteitsproblemen voor inspectie en behandeling naar kantoor vervoerd. De Net.App van TrueServer dient ondertussen al enige dagen als fileserver.
- 06-09 Wederom was Argus aan het bokken. Dit leverde de (helaas al bekende) 403 pagina's op. In de haast om Argus weer up te krijgen werden ook Alicia en Artemis gereboot, daar dit niet de bedoeling was duurde het een tijdje voor beide servers weer up waren. Binnenkort zullen we van Argus geen last meer hebben want Tweakers.net kan tijdelijk een Net.App testen. Afhankelijk van de ervaringen daarmee zullen we mogelijk zelf zo'n apparaat aanschaffen.
- 02-09 Wederom waren er vanmorgen problemen. Ineens lagen Apollo en Argus eruit. Een reboot gaf tot resultaat dat Argus weer tot leven kwam en daarmee ook de frontpage. Apollo laat het tot nu toe nog steeds afweten, waardoor het forum down is. Floris is de held van de dag; hij is inmiddels vertrokken naar Amsterdam.
- 01-09 Daar Argus, de Atlas vervangende fileserver, er voor verkoos plat te gaan voordat er een backup geregeld was heeft Tweakers.net er deze ochtend uitgelegen. Ook Apollo en Artemis verkozen ervoor down te gaan. Dat dit allemaal zo snel opgelost is, is te danken aan Marcel die weer en wind trotseerde om naar Telecity te rijden en daar onze servers weer aan te slingeren, nogmaals bedankt Marcel!
Server & netwerk statusmeldingen
Reacties (278)
Is er een verband tussen het uitvallen van de fileservers en de webservers? En is het niet zo dat t.net normaal ook een gecachde versie weer kan geven? Is het niet een idee om het zo te configureren dat zodra een paar webservers onbereikbaar worden er wordt overgeschakeld naar die gecachde versie om zo te voorkomen dat de ander ook plat gaat?
Wordt het niet tijd dat Kees bij Telecity gaat inwonen?
Wordt het niet tijd dat Kees bij Telecity gaat inwonen?
Tuurlijk heeft het verband met elkaar als er een fileserver plat gaat dat dan de rest onderketst. In elke server opstelling zit ene zwakke schakel en 9 van de 10 keer heet die fileserver. Als er dan spontaan een hoop load op je interne netwerkje komt en die kan niet evrwerkt worden knalt de rest eruit doordat de servers vollopen tot 100% CPU en Mem gebruik. Einde verhala dan....
edit:
Ik geloof dat TRUEserver geen half rack emer over had om Kees in te laten slapen...
Ik geloof dat TRUEserver geen half rack emer over had om Kees in te laten slapen...
Nou, dan zou ik als ik jou was toch geen systeembeheerder worden, want het is NIET normaal dat de webservers down gaan als de fileserver down gaat. Dat er niks op het scherm verschijnt is logisch, maar ze dienen NIET down te gaan..Tuurlijk heeft het verband met elkaar als er een fileserver plat gaat dat dan de rest onderketst.
Ik zie je al aankomen: "Ja, baas, de fileserver ging down, en daarom gingen dus ook alle andere printservers, mailservers, webservers en databaseservers en alle andere servers ook down". Ik denk dat je snel op zoek zou kunnen gaan naar een andere baan....
Dat is niet helemaal waar, het is een logisch vervolg, jij kunt mij namelijk sterk vertellen dat het anmelijk toeval is!
Vertel mij maar eens waraom mijn voleldige theorie niet klopt. Als je idd zo'n goede sysop bent als je hier zo beweerd dan kun je mij ook exact vertellen wat er dan allemaal zou gebeuren als de fileserver down is en je hele netwerkje volloopt met timeouts...
Vertel mij maar eens waraom mijn voleldige theorie niet klopt. Als je idd zo'n goede sysop bent als je hier zo beweerd dan kun je mij ook exact vertellen wat er dan allemaal zou gebeuren als de fileserver down is en je hele netwerkje volloopt met timeouts...
Als je als file server een doos gebruikt dan heb je dit probleem wel tenzij de head dubbel uitgevoerd is zoals bij een net app kan. Die cluster je gewoon en gaat beestje 1 dood dan kan nummer 2 het overnemen. Het is maar net waar je je opslag wilt doen met 0.5TB gaat het een beetje moeilijk intern in de server in de meeste gevallen :-)
Cobalts zijn bijvoorbeeld zo ingesteld dat bij een te hoge load bv sendmail eruit gaat. Daarnaast kan een te hoge load ook betekenen dat je uiteindelijk langer moet wachten op db-connecties. Weer meer geheugen in gebruik en als dit vast loopt krijg je melding als
FATAL: emalloc(): Unable to allocate 343878 bytes\
etc, en aangezien apache op zich wel geheugen gebruikt tijdens het functioneren kan het niet aanwezig zijn van geheugen tot gevolg hebben dat de doos nog wel te pingen is maar geen http kan aanbieden aan clients.
FATAL: emalloc(): Unable to allocate 343878 bytes\
etc, en aangezien apache op zich wel geheugen gebruikt tijdens het functioneren kan het niet aanwezig zijn van geheugen tot gevolg hebben dat de doos nog wel te pingen is maar geen http kan aanbieden aan clients.
"Ja, baas, de fileserver ging down, en daarom gingen dus ook alle andere printservers, mailservers, webservers en databaseservers en alle andere servers ook down".
Daar komt nog bij dat die baas zich achter de oren zal krabben, waarom ie de recente (dure) upgrade heeft goedgekeurd. Er zal wel weer behoorlijk op zijn ingepraat dat dit echt noodzakelijk is en beter, sneller, stabieler, betrouwbaarder..... alleen baassie krijgt de rekening, die ook, hoger, duurder, groter is dan anders.
Baas zal zich nu afvragen of het dat geld wel waard is geweest.
Redenatie Alex de Groot is typisch voor een systeembeheerder, redenatie valt niks op aan te merken, maar al die lui die niet kunnen inloggen/browsen/printen/mailen hebben daar absoluut schijt aan. Moet gewoon werken. Beter werken. DAAR was die upgrade voor. Dat er problemen zijn na een upgrade IS niet vanzelfsprekend, dat het gebeurt is een tweede, maar as systeembeheerder maak je dus fouten blijkbaar, simpel. Maak niet uit, nobody's perfect, maar het is ook typisch voor een systeembeheerder om de fout bijna altijd in het materiaal te gaan zoeken of de software, je weet wel , dezelfde software/hardware die men eerst volop prees as onmisbaar / beter / betrouwbaarder....
Wildhagen heeft wel gelijk door te stellen dat het niet normaal is dat alles plat gaat. Als het dat wel is, is het nl. een errug zware SPOF. Kun je de rest wel zwaar redundant hebben, maar ja....daar schiet je niks mee op dan he.
Ik zou knap zenuwachtig worden als ik mijn productie platform op jullie servers zou hebben draaien, sorry, maarruh ik kan mijn klanten NIET uitleggen 'dat de fileserver nukken heeft en dat de rest van het netwerk er dan uit knalt....' ik ben dan geheid een deel van mijn klanten kwijt of moet ik met kortingen gaan lopen strooien. Zo werkt het nl. ook nog 's in de 'real' world, in ieder geval wel in onze business.
Daar komt nog bij dat die baas zich achter de oren zal krabben, waarom ie de recente (dure) upgrade heeft goedgekeurd. Er zal wel weer behoorlijk op zijn ingepraat dat dit echt noodzakelijk is en beter, sneller, stabieler, betrouwbaarder..... alleen baassie krijgt de rekening, die ook, hoger, duurder, groter is dan anders.
Baas zal zich nu afvragen of het dat geld wel waard is geweest.
Redenatie Alex de Groot is typisch voor een systeembeheerder, redenatie valt niks op aan te merken, maar al die lui die niet kunnen inloggen/browsen/printen/mailen hebben daar absoluut schijt aan. Moet gewoon werken. Beter werken. DAAR was die upgrade voor. Dat er problemen zijn na een upgrade IS niet vanzelfsprekend, dat het gebeurt is een tweede, maar as systeembeheerder maak je dus fouten blijkbaar, simpel. Maak niet uit, nobody's perfect, maar het is ook typisch voor een systeembeheerder om de fout bijna altijd in het materiaal te gaan zoeken of de software, je weet wel , dezelfde software/hardware die men eerst volop prees as onmisbaar / beter / betrouwbaarder....
Wildhagen heeft wel gelijk door te stellen dat het niet normaal is dat alles plat gaat. Als het dat wel is, is het nl. een errug zware SPOF. Kun je de rest wel zwaar redundant hebben, maar ja....daar schiet je niks mee op dan he.
Ik zou knap zenuwachtig worden als ik mijn productie platform op jullie servers zou hebben draaien, sorry, maarruh ik kan mijn klanten NIET uitleggen 'dat de fileserver nukken heeft en dat de rest van het netwerk er dan uit knalt....' ik ben dan geheid een deel van mijn klanten kwijt of moet ik met kortingen gaan lopen strooien. Zo werkt het nl. ook nog 's in de 'real' world, in ieder geval wel in onze business.
Nu is er wel weer genoeg ruzie gemaakt 
Hoe kan het dat al die bakken er op hetzelfde moment voor "kiezen" down te gaan?
Okay, aangezien ik gister geen antwoord kreeg en vandaag dus *weer* meerdere servers *tegelijk* uitvallen.. hoe kan dat toch?
Hoort die loadbalancer dit soort uitvallen (v.d. frontpage) niet op te vangen? Functioneert het apparaat dan gewoon niet, of is hij niet (goed) geconfigureerd om dit te voorkomen?
Hoort die loadbalancer dit soort uitvallen (v.d. frontpage) niet op te vangen? Functioneert het apparaat dan gewoon niet, of is hij niet (goed) geconfigureerd om dit te voorkomen?
Als de fileserver uitvalt hebben de webservers geen content meer. Daarnaast geeft elk process wachtend op file IO een load van 1 extra. 50 httpd's die op io staan te wachten geven al een load van 50.
De loadbalancer kijkt oa naar de load. Op een bepaald moment zullen alle webservers met een hoge load staan te wachten. Hierdoor zal de loadbalancer geen enkele web server meer gebruiken en is de site dus geheel buiten gebruik.
Een hele hoge load veroorzaakt door wachtende io veroorzaakt trouwens geen crash.
De loadbalancer kijkt oa naar de load. Op een bepaald moment zullen alle webservers met een hoge load staan te wachten. Hierdoor zal de loadbalancer geen enkele web server meer gebruiken en is de site dus geheel buiten gebruik.
Een hele hoge load veroorzaakt door wachtende io veroorzaakt trouwens geen crash.
Ik ken de gevolgen van een onbereikbare NFS server, en dat is inderdaad erg vervelend.
Het lijkt me niet meer dan logisch dat kees wel een constructie heeft bedacht dat er een on-disk versie van de webroot gebruikt wordt als NFS niet werkt. True, de httpds die op dat moment draaien blijven in uninterruptable state, maar de "nieuwe" httpds kunnen dan gewoon verder draaien.
Als zo'n constructie er niet is, dan zou dat inderdaad verklaren waarom de site plat ligt door iets als dit. En rendert het de loadbalancer volledig overbodig, en dat is zo dom dat dat vast niet het geval is. </sarcasm>
Dit is echter onzin.Als de fileserver uitvalt hebben de webservers geen content meer.
Het lijkt me niet meer dan logisch dat kees wel een constructie heeft bedacht dat er een on-disk versie van de webroot gebruikt wordt als NFS niet werkt. True, de httpds die op dat moment draaien blijven in uninterruptable state, maar de "nieuwe" httpds kunnen dan gewoon verder draaien.
Als zo'n constructie er niet is, dan zou dat inderdaad verklaren waarom de site plat ligt door iets als dit. En rendert het de loadbalancer volledig overbodig, en dat is zo dom dat dat vast niet het geval is. </sarcasm>
Och Rick, toen jij de touwtjes nog in handen had is er anders ook genoeg fout gegaan...
Hans. Nee, ik begrijp natuurlijk heel goed waarom dit er nu weer bijgehaald moet worden. 't Is zo lekker makkelijk he, ik had ook niks anders van je verwacht. Wil je even je offtopic replies voor je houden? Dank je.
Met al die servers had je makkelijk even een /etc/exports kunnen kopieren naar een andere server en de nfsd aan kunnen zetten. Dat is maximaal een kwartiertje werk, en het scheelt je zo een hele ochtend aan downtime, en dus een hoop kosten (o.a. een tank benzine om naar Amsterdam te rijden).Die constructie was er wel (iig, switch direct naar een andere NFS server) maar die andere NFS server is vrijdag uit het rack gehaald, en ik heb nog geen tijd gehad om een vervangende NFS server te maken. (ik doe ook andere dingen naast t.net)
Die constructie was er wel (iig, switch direct naar een andere NFS server) maar die andere NFS server is vrijdag uit het rack gehaald, en ik heb nog geen tijd gehad om een vervangende NFS server te maken. (ik doe ook andere dingen naast t.net)
Ik denk dat Kees dat ook heel erg graag wil weten
Hebben jullie Marcel (die geen zekeringen bevat 
) verkozen boven de masterswitch, of hangt die er niet meer 
.
) verkozen boven de masterswitch, of hangt die er niet meer 
.
Ik ben blij dat er mensen zijn die zich zo inzetten om alles wat we hier zien op tweakers werkend te houden.
Ik ben blij dat ze vooruit denken en proberen de boel zo op te zetten zodat wij in de toekomst kunnen blijven genieten !
Als dat inhoudt dat we soms een beetje downtime voor ons kiezen krijgen, vind ik dat acceptabel.
, hier staat namelijk geen miljoenen verslindend bedrijf achter !
En voor alle mensen die het beter weten, regel maar een sponser contractje, zodat alle dure ideeën kunnen worden uitgevoerd.
Ik ben blij dat ze vooruit denken en proberen de boel zo op te zetten zodat wij in de toekomst kunnen blijven genieten !
Als dat inhoudt dat we soms een beetje downtime voor ons kiezen krijgen, vind ik dat acceptabel.
, hier staat namelijk geen miljoenen verslindend bedrijf achter !En voor alle mensen die het beter weten, regel maar een sponser contractje, zodat alle dure ideeën kunnen worden uitgevoerd.
t.net krijgt elke dag meer bezoekers en wordt elke dag groter (artikels, GoT, ...) ik denk dat we blij mogen zijn dat het nog zo snel gaat allemaal
Voor de mensen die problemen hebben dat t.net af en toe enkele uurtjes down is: get a life?
Voor de mensen die problemen hebben dat t.net af en toe enkele uurtjes down is: get a life?
Is er al bekend aan welke kuren Argus ten onder is gegaan, en wanneer de terugkeer van Argus te verwachten is?
En toch stem ik voor Dell-servers, in plaats van zelfbouw machines . Het komt toch redelijk voor dat er dingen sterven, niet waar? Ik weet wel dat het ook anders kan ja (heb 't zelf tenslotte ook), maar toch denk ik dat het een heleboel downtime kan besparen.
. Het komt toch redelijk voor dat er dingen sterven, niet waar? Ik weet wel dat het ook anders kan ja (heb 't zelf tenslotte ook), maar toch denk ik dat het een heleboel downtime kan besparen.
De enige server die echt vaak plat ging de laatste tijd was juist de enige niet-zelfbouw bak
Heb je enig idee hoeveel geld Tweakers.net BV kwijt is als ze de complete server omgeving gaan vervangen met bijvoorbeeld Dell servers
En wie zegt dat de zelfgemaake servers de oorzaak was van deze downtime
En wie zegt dat de zelfgemaake servers de oorzaak was van deze downtime
Um, _waarom_ zou een niet zelfgebouwde server minder vaak door softwarematige problemen plat gaan dan een niet zelfgebouwde server?
Ik weet niet wat de exacte redenen van deze crash waren, maar ik denk zomaar niet dat Dell servers er geen last van hadden gehad.
Ik weet niet wat de exacte redenen van deze crash waren, maar ik denk zomaar niet dat Dell servers er geen last van hadden gehad.
Als je per se dure constructies moet gebruiken, doe het dan goed.Daar Argus er voor verkoos
("Daar Argus het verkoos" dus)
Beter een taalkundig minder juiste mededeling dan geen mededeling
Idd, Kees moet eens wat beter op zijn spelling letten. Dit lijkt nergens op 
Dat is geen spelfout, dat is een fout in de zinsconstructie 
Toch weer mooi van dat loadbalancing, er hoeft er maar eentje recalcitrant te zijn en alles is down
Dat hoeft niet per sé, als er één webserver plat zou gaan, en de rest zou draaien zou die loadbalancer gewoon alle requests naar de wel werkende servers moeten re-routen.
Maar ja, in dit geval ging de fileserver down, en als dat het enige exemplaar is, is die loadbalancer ook snel klaar natuurlijk...
Maar ja, in dit geval ging de fileserver down, en als dat het enige exemplaar is, is die loadbalancer ook snel klaar natuurlijk...
Als hiermee wordt bedoelt, resetten: waar is de op afstand bedienbare server resetter?Dat dit allemaal zo snel opgelost is, is te danken aan Marcel die weer en wind trotseerde om naar Telecity te rijden en daar onze servers weer aan te slingeren, nogmaals bedankt Marcel.
daarvoor moet een PC toch aanstaan/in verbinding met internet staan
Nej.
T.net heeft/had () een zogenaamde masterswitch.
Zie dat maar als een stopcontact met een netwerkaansluiting. Je kan dus gewoon de stroom dan van de server afhalen en die er weer opzetten, en dus gewoon resetten ook al is de server onbereikbaar.
T.net heeft/had (
) een zogenaamde masterswitch. Zie dat maar als een stopcontact met een netwerkaansluiting. Je kan dus gewoon de stroom dan van de server afhalen en die er weer opzetten, en dus gewoon resetten ook al is de server onbereikbaar.
Ik denk dat die er nog steeds in zit (hebben dat ding niet voor niets aangeschaft ) In 1 van de filmpjes kon ik hem nog heel even zien maar hij zat volgens mij nog niet helemaal vol (2 aansluitingen gebruikt als ik vlug kijk) en volgens mij hebben ze ook meer servers dan aansluitingen op de masterswitch dus het kan zijn dat die er toevallig niet op zaten...
) In 1 van de filmpjes kon ik hem nog heel even zien maar hij zat volgens mij nog niet helemaal vol (2 aansluitingen gebruikt als ik vlug kijk) en volgens mij hebben ze ook meer servers dan aansluitingen op de masterswitch dus het kan zijn dat die er toevallig niet op zaten...
Ik zie hem inderdaad op het filmpje.
Alleen zie ik dat er 6 aansluitingen gebruikt worden
Misschien was die ene server nou net niet aangesloten op de masterswitch, want ik geloof dat er momenteel meer servers dan masterswitch aansluitingen zijn.
Alleen zie ik dat er 6 aansluitingen gebruikt worden
Misschien was die ene server nou net niet aangesloten op de masterswitch, want ik geloof dat er momenteel meer servers dan masterswitch aansluitingen zijn.
Er hangen 2 APC Masterswitches. Daarmee kun je dus een server remote 'herstarten'. Als je na een reboot een kernel panic krijgt of je moet een fsck uitvoeren heb je nog weinig aan zo'n apparaat. Dat is in 33% van de gevallen zo schat ik? Ext3 is wel een oplossing in zo'n geval zeg maar.
Draaien die servers niet op ext3 dan . Lijkt me wel handig, voor jou en voor Kees.
. Lijkt me wel handig, voor jou en voor Kees.
Met zo'n zware load vergt ext3 teveel overhead, XFS of ReiserFS zijn dan beter.
Op dit item kan niet meer gereageerd worden.