Falende fileserver

[djc]

Ik heb de laatste tijd steeds sterker het idee dat de servers waar de CSS en images voor React vandaan moeten komen de load niet helemaal aankunnen. De helft van de pageloads op GoT die ik doe missen een plaatje, een stylesheet of ik krijg een cannot find server or dns error. Zelfs op dit uur, nu het niet zo druk is op GoT, gebeurt dit voortdurend. Best vervelend...

Ik weet niet of dit al een known problem is of of meerdere mensen hier last van hebben?

[Harm]

http://images.tweakers.net langzaam en Smilies werken vaak niet

[D2k]

known problem
de netapp die nu de fileserver vervangt gaat regelmatig onderuit
voordeel is wel dat ie zichzelf reboot dus binnen een aantal minuten lost het zichzelf op

[ripexx]

Server & netwerk statusmeldingen II

Dit is de netapp die zich zelf reset of iets in die richting. Zie ook eerdere meldingen.

edit
Damm D2k

[djc]

Wanneer komt er weer een normale fileserver of een betere netapp?

[JvS]

Ze zijn er mee bezig. Als we wisten hoe we het snel konden oplossen: snel... We hebben niet geld om even een nieuwe fileserver te kopen...

[Coen Rosdorff]

In de huidige opzet is zelfs een netapp niet zwaar genoeg om als file-server te dienen. Toch de content maar weer eens lokaal op de servers zetten dan, en de boel met elkaar syncen mbv rsync. De huidige oplossing is niet echt schaalbaar zo blijkt.

[ACM]

Ah meneer de expert

[RvdH]

't Is ook nogal nutteloos om de redundancy van loadbalancers e.d. onderuit te halen met een SPOF zoals die NetCrapp

[Wilke]

strlen schreef op 11 oktober 2002 @ 22:53:
't Is ook nogal nutteloos om de redundancy van loadbalancers e.d. onderuit te halen met een SPOF zoals die NetCrapp

Het is ook vrij nutteloos om redundancy te hebben als er vervolgens niets is om data vandaan te serven.

Kees is hard aan het knutselen aan een distributed FS oplossing (zoals Coda of AFS), maar dat is dus nog niet klaar. Tot die tijd is er gewoon weinig keus (behalve gebruik maken van een nog brakkere oplossing zoals NFS op een eigen server, zoals eerst het geval was, maar dat werkte dus nog minder goed).

De net.app zou erg stabiel moeten zijn, maar de load is blijkbaar te hoog...hij trekt 't gewoon niet.

[ACM]

Wilke schreef op 11 oktober 2002 @ 22:59:
Het is ook vrij nutteloos om redundancy te hebben als er vervolgens niets is om data vandaan te serven.

Kees is hard aan het knutselen aan een distributed FS oplossing (zoals Coda of AFS), maar dat is dus nog niet klaar. Tot die tijd is er gewoon weinig keus (behalve gebruik maken van een nog brakkere oplossing zoals NFS op een eigen server, zoals eerst het geval was, maar dat werkte dus nog minder goed).

De net.app zou erg stabiel moeten zijn, maar de load is blijkbaar te hoog...hij trekt 't gewoon niet.

Yups, dat is idd de gang van zaken, helaas is het niet echt makkelijk zoiets snel over te zetten, zeker als je niet zomaar even (nog) een server er tussen "uit kan trekken".

[RvdH]

Wat is er zo bijzonder aan react/t.net/fok dat files niet meer lokaal van de hd geserveert kunnen worden (icm rsync, zoals little_soundman al suggereerde)?

[ACM]

strlen schreef op 11 oktober 2002 @ 23:04:
Wat is er zo bijzonder aan react/t.net/fok dat files niet meer lokaal van de hd geserveert kunnen worden (icm rsync, zoals little_soundman al suggereerde)?

Onder andere de prut als usericons en vergelijkbare zaken.
Magoed er is nergens gezegd dat rsync niet kan. Maar we hebben de voorkeur voor wat anders.

[RvdH]

Waarom zou je usericons op meerdere servers willen zetten

[ACM]

strlen schreef op 11 oktober 2002 @ 23:14:
Waarom zou je usericons op meerdere servers willen zetten

Omdat de uploadscripts op meerdere servers uploaden

[RvdH]

Waarom doen ze dat dan?
Die form tag kun je best naar een specifieke server laten wijzen qua action=, en het aanroepen van de icons ook

[ACM]

strlen schreef op 11 oktober 2002 @ 23:17:
Waarom doen ze dat dan?
Die form tag kun je best naar een specifieke server laten wijzen qua action=, en het aanroepen van de icons ook

Tuurlijk kan dat

Maar dan introduceer je alweer een nieuwe spof (een wat minder ernstige, maar toch).
Anyway, er zijn meerdere mogelijkheden om ons "probleem" op te lossen. Rsync achtige zaken zijn er een van.
Een andere is bijv het inzetten van een Dfs, zoals coda, wij denken dat coda het allemaal net iets beter/makkelijker doet dan rsync.
Mede omdat coda ervoor geschreven is files te sharen, rsync alleen maar om lokale dirtree's synchroon met die van een of andere server te houden.
Btw, als de keuze uiteindelijk zou worden rsync+nfs (ofzo) vs nfs dan kiezen we heus wel voor rsync+nfs.
Want over het lokale HD gedeelte heb je in principe natuurlijk gelijk, het idee achter coda is echter dat dat allemaal automatisch voor je gedaan wordt. Zeker als je de caches groot genoeg neemt (paar honder mb zou ruim voldoende moeten zijn in onze setup).

[RvdH]

Dus jullie hebben liever dat het forum en heel t.net plat ligt, dan dat de usericons niet te zien zijn.
Zo mooi zijn die icons nou ook weer niet hoor.

Ik heb zelf geen ervaring met coda, maar weet wel dat rsync specifiek voor dit soort doeleindes ontwikkeld is. Hoe vaak verandert nou de source van een website?

Door coda te gebruiken stress je je eigen interne netwerk, en disks meer als dat je 1 x per dag een rsync doet.

Ik neem aan dat coda met een daemon process draait... dan heb je dus ook weer een hoop aantal processen erbij, die continue geheugen gebruiken e.d., wat rsync maar 1 keer hoeft te doen op 1 server

Was de mening overigens niet een maand geleden nog dat distributed file systems niet helemaal voldeden?

[Coen Rosdorff]

ACM schreef op 11 oktober 2002 @ 23:13:
Onder andere de prut als usericons en vergelijkbare zaken.
Magoed er is nergens gezegd dat rsync niet kan. Maar we hebben de voorkeur voor wat anders.

Pak dan rsync voor de statische dingen, en zet de icons wel op een share. Dat scheelt minimaal 80% van de requests op de fileserver.

Of schrijf vanaf de webservers naar de file-server, en trek dan elke 5 min de boel met rsync weer over. Zelfs met nfs moet het goed te doen zijn op 8 servers elke 5 min te laten syncen.

[ACM]

Ja, dat is dus keuze 2 uit ons keuze lijstje.
Keuze 1 is coda, die theoretisch hetzelfde doet, maar dat integreert en automatisch afhandelt. Naast een betere failure support.