Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 115 reacties

Zoals jullie ondertussen vast wel doorhebben, worden de afbeeldingen in de content, avatars en diverse andere plaatjes sporadisch of helemaal niet weergegeven. Dit komt doordat onze centrale iSCSI-server Athos er inmiddels volledig de brui aan heeft gegeven. Het daarop liggende OCFS 2-filesysteem heeft voor de verandering redelijk weinig met de problemen te maken.

Gistermiddag bleek dat een disk van de raid5-array van Athos als 'failed' gezien werd. Helaas weigerde de controller echter om de reserveschijf (blijvend) in gebruik te nemen en ook een nieuwe disk wordt door Athos structureel genegeerd. Een en ander is ondertussen zó onduidelijk, zowel voor ons als voor de support-afdeling van Dell, dat we een andere machine als storageserver aan het inrichten zijn. Daardoor zouden we in ieder geval morgen een oplossing voor deze situatie moeten hebben, ook als Athos dan nog steeds loopt te bokken.

Hoelang de problemen nog aanhouden is ons dus helaas ook niet bekend. Hoewel we niet vreselijk veel data op Athos opslaan, gaat het toch over behoorlijk wat gigabytes aan kleine files. Zelfs het kopiëren uit de backup kost daardoor veel tijd. We proberen in elk geval om het ongemak zo snel mogelijk te verhelpen.

Update:

Ondertussen is een andere server aangesteld om de data die op Athos stond, via nfs aan te bieden. Aangezien we al bezig waren met een permanente vervanger voor het iSCSI+OCFS 2-verhaal, verwachten we dat deze oplossing hooguit enkele weken in gebruik blijft.

Zodra we die nieuwe oplossing in gebruik nemen, kondigen we dat uiteraard weer met een .plan aan.

Door Arjen van der Meijden

- Lead Developer

In oktober 2001 begonnen met als voornaamste taak het technisch beheer van het forum. Daarna doorgegroeid tot senior developer en softwarearchitect. Nu lead developer, met een leidinggevende taak binnen het team van programmeurs en systeembeheerders van Tweakers.

Moderatie-faq Wijzig weergave

Reacties (115)

1 2 3 ... 6
Grappig om te lezen dat er nu met veel begrip gereageerd wordt, maar wanneer bijvoorbeeld een internetprovider of telecomaanbieder een storing heeft er al snel gereageerd wordt in de trend van "hoe kan dit", "Ze hebben hun zaakjes niet goed op orde" etc.

Uiteraard kunnen dit soort dingen gebeuren en de wet van Murpy kan hier ook toeslaan. Ik hoop dat jullie het probleem snel op kunnen lossen :)
Twee redenen: Voor een internetverbinding wordt betaald. Daarnaast communiceert tweakers.net heel openlijk over problemen en gaat daar inhoudelijk ook nog eens op in. Dat kweekt begrip.

Daarnaast voelen veel geregistreerde bezoekers zich een onderdeel van de community tweakers.net.

Stiekem drie redenen dus :P
Voor een internetverbinding wordt betaald.
Grotendeels heb je natuurlijk een punt, maar ook veel tweakers die geen klant zijn bij betreffende aanbieders vallen een falende provider al snel af. Dan hebben ze dus niet een geldelijk belang.

Voor een internetaanbieder is het natuurlijk lastig om zo'n sterke band met hun gebruikers op te bouwen.
Bij een internetprovider is het leveren van connectiviteit de core business.
Bij Tweakers.net is het schrijven van stukjes over tech de core business.

Bij Tweakers.net zouden ze hun zaakjes niet goed op orde hebben als ze slechte stukjes vol met spelfouten en/of onwaarheden zouden schrijven. Gelukkig valt dat wel mee, maar je ziet ook wel dat de hardste kritiek op Tweakers.net altijd inhoudelijk/redactioneel van aard is.

Het omgekeerde zou zijn dat er krom Nederlands op de voorpagina van mijn ISP staat. Tsja, dan zal ik daar vast wel om lachen, maar zolang mijn verbinding maar werkt ga ik niet de klantenservice bellen.
Aha, ik begon al te twijfelen aan mijn computer.
Maar er is dus een aparte server voor alleen de afbeeldingen, ik dacht dat dat allemaal op een server werd gehost.
Tegenwoordig worden bij websites met veel traffic (zoals tweakers) de afbeeldingen en scripts vaak op een andere server gehost. Als ik me niet vergis is dit om enige snelheidswinst te behalen bij het laden van een pagina.
Dit heeft er mee te maken dat er maar een beperk aantal verbindingen naar een server kunnen worden gelegd door de client. Doordat de afbeeldingen via een ander domein te laten lopen kunnen er in totaal meer verbindingen worden ingezet voor het opbouwen van de pagina.

Het domein dat T.net gebruikt voor zijn afbeeldingen is ic.tweakimg.net
Ook omdat dit domein niet met cookies werkt levert dit een kleine snelheidswinst op per client maar in totaal is dit wel redelijk te noemen.

Voor meer informatie kun je hier verder lezen: plan: Content-afbeeldingen voortaan via ic.tweakimg.net
[q]Dit heeft er mee te maken dat er maar een beperk aantal verbindingen naar een server kunnen worden gelegd door de client. [/q
Overigens gaat het alleen om een ander domein, het is niet per se noodzakelijk om hier ook een fysiek andere server voor de gebruiken. Als je het echter om een site met veel trafic hebt, zoals tweakers.net, dan is het vaak weer wel zinnig om dit soort zaken fysiek te scheiden - de rest van de uitleg klopt wel overigens :)

Bij t.net is er dus ook een scheiding tussen de server die voor de plaatjes zorgt, de database server, de "front end" server ("tweakers.net"), file server en nog een aantal andere servers...
Volgens de http-specificatie hoort een client niet meer dan 2 verbindingen met een webserver te hebben. Meer servers is dus ook meer gelijktijdige downloads.

Zie daarvoor RFC2616 8.1.4 Practical Considerations
http://www.faqs.org/rfcs/rfc2616.html\
<quote>
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.
</quote>
In Firefox lijkt 6 connectionsr inmiddels standaard? network.http.max-persistent-connections-per-server
Clients that use persistent connections SHOULD limit the number of
simultaneous connections that they maintain to a given server. A
single-user client SHOULD NOT maintain more than 2 connections with
any server or proxy. A proxy SHOULD use up to 2*N connections to
another server or proxy, where N is the number of simultaneously
active users. These guidelines are intended to improve HTTP response
times and avoid congestion.
1. Er staat 'should' en niet 'must'. Er is dus geen sprake van dwang. Hooguit een zeer dringend advies.
2. Er wordt gesproken over 'guidelines'. Het wordt dus aangeraden, maar is niet verplicht. Even een quote van Wikipedia: "By definition, following a guideline is never mandatory (protocol would be a better term for a mandatory procedure)."

Misschien een kwestie van interpretatie, maar nergens staat IMO dat een client maar 2 connections hoort aan te gaan. Er staat alleen dat geadviseerd wordt dat een client niet meer dan 2 connecties aangaat.

Overigens zou IE8 standaard ook maximaal 6 connecties aangaan. (http://www.stevesouders.c.../10/ie8-speeds-things-up/)

Rechtstreekse bron: http://www.microsoft.com/...iness/developers-new.aspx.
Six connections per host for broadband scenarios instead of two, and a scriptable property, improve performance by allowing parallelization of downloads in Internet Explorer 8. This also increases functionality by ensuring that a request is not blocked to a host if two connections already exist. Websites can optimize downloads based on the window.maxConnectionsPerServer property.
Het document dat je aanhaalt is zo te zien inmiddels ruim 10 jaar oud (1999), in die tijd is de capaciteit van servers drastisch gestegen. Je kan je dus afvragen of dit advies inmiddels niet achterhaalt is.

[Reactie gewijzigd door Aganim op 20 januari 2010 01:02]

Tegenwoordig worden bij websites met veel traffic (zoals tweakers) de afbeeldingen en scripts vaak op een andere server gehost. Als ik me niet vergis is dit om enige snelheidswinst te behalen bij het laden van een pagina.
Dat, maar ook kun je door fysiek verschillende servers te gebruiken die servers specialiseren. Een fileserver heeft zo op zich geen enorm sterke processor nodig, maar wel goede storage (veel ruimte, redundantie) en een stevige netwerkverbinding. Een databaseserver heeft vooral snelle opslag en verwerkingssnelheid nodig, maar hoeft geen verbinding met de boze buitenwereld te hebben (en een DB server wordt natuurlijk in tweevoud opgeleverd). En tenslotte een webserver, die weinig opslag nodig heeft (daar de PHP scripts van T.net weinig ruimte innemen), maar wel een stevige processor om de zaak te berekenen.
Een databaseserver heeft vooral snelle opslag en verwerkingssnelheid nodig, maar hoeft geen verbinding met de boze buitenwereld te hebben
Euhm ik wil niet moeilijk doen, maar een database server die geen connectie met de buitenwereld heeft is een waardeloze server... en een goede verbinding ook als je latentie en bandwith wat onder controle wil houden.
Een db server heeft bijna (helaas komt het nog wel eens voor) nooit verbinding met de grote boze buitenwereld (het internet) nodig, het is voldoende als de webserver hem kan bereiken. Ook al ben ik een tweaker ik heb er geen behoefte aan om met een MySQL client t.net te lezen ;).
een db server die in verbinding staat met een webserver is toch wel indirect verbinding met de boze buitenwereld? dat is toch juist de manier hoe mensen in belangrijke zogenaamd goed beveiligde projecten kan komen, door 1 andere pc die wel met internet als beveiligde ding is verbonden? het is misschien wel lastiger om erin te komen via de buitenwereld, maar het kan vast nog wel.

en voor debugging is het soms ook wel leuk om de database te kunnen bereiken hoor, dat je niet eerst naar de serverruimte moet om daar verbinding te maken
Aan de andere kant moet er ook een DNS look-up gedaan worden (eenmalig voor de eerste request tot de cache TTL verstreken is). Dit kost vaak ook nog wel aardig wat tijd (van +/- 100ms tot soms wel 1000ms).

Maar uiteraard is het uiteindelijk voor een site als t.net voordeliger, omdat er behoorlijk wat statische content geladen moet worden.
Haha, dacht hier het zelfde.
Dacht van doet mn pc toch vreemd.

Maarja hoop dat jullie de boel weer draaiden kunnen krijgen en anders ook niet direct een ramp omdat het alleen wat kleinere bestanden betreft.

En zoals DJT88 al zij, Success met fixen :P
Haha ik was dus niet de enige met die gedachte! Ik was ook al aan het updaten geslagen |:( hehe :+

Maare, succes met de herstelwerkzaamheden mannen!
ik dacht dat het aan m'n FF en caching lag, die dus beide gechecked en ook de site eens in IE geopend, maar daar hetzelfde probleem: conclusie was dus redelijk snel dat het server-sided moest zijn
Ik had hier gisteravond al last van, dacht ook dat het aan m'n pc lag dus flashplayer geupdate en al die meuk.. Nog geen resultaat :P
Succes met de rebuild!
Maak er maar veertien losse servers van. Natuurlijk niet allemaal bezig met maar 1 specifieke taak, maar toch.
Ik had een zelfde soort reactie, alhoewel ik er na een snelle check al achter was dat het niet aan mij lag, is dat toch de eerste aanname die je maakt. T.net heeft het altijd zo goed voor elkaar dat je gewend bent dat dit de enige site is op internet die het altijd doet. Wat ook blijkt uit het feit dat een ernstig bokkende server minimale interruptie oplevert en heel rap vervangen is. :)

Ga zo door mannen! En veel succes met fixen. :)
Vandaar dat iedereen altijd zit te drammen: "RAID = GEEN BACKUP" :)
Klopt inderdaad.
Nu is het hier wel een specifiek geval omdat de controller de reserve n een nieuwe schijf niet wilde accepteren. In eerste instantie dacht men het probleem te hebben gelocaliseerd in een firmware maar blijkbaar is dit toch ook nog niet het geval.

Wel mooi om te zien dat T.net altijd problemen vind die vaak nog niet bekend zijn. Er was een tijdje geleden ook een bug in MySQL gevonden door T.net
die firmware moeten we nog update, maar dat lukt niet omdat die schijf nog als failed te boek staat.

En inderdaad, we vinden toch redelijk vaak problemen die we dan maar weer als bug raporteren. zoal laatst in mysql replicatie een showstopper, een query in mysql die de volledige server liet crashen, mysql met ext4 bugs, LVS kernel modules die niet volgens een juiste logica werken, LVS kernel modules die niet met multi-cpu systemen overweg kan etc.

Nu zullen andere bedrijven ongetwijfeld daar ook wel tegenaanlopen en het fixen, maar wij melden het dan meestal ook even ;)
Nu vraag ik mij wel af om wat voor een RAID en controler het hierbij gaat? Wat de evt. oplossing is en of het een specifiek probleem is.

Wij bezitten op de zaak ook een aantal DELL machines waarvan er twee met een DAS welke ook in RAID5 staan met hotspare.

Als dit een algehele ziekte is vraag ik mij namelijk af of dell dit ook structureel op gaat lossen of wacht tot het probleem naar hun komt.
Hoewel het niet een directe ramp zou zijn voor ons omdat ze minder dan vier uur de tijd hebben om het te repareren :)
Nou, wij hebben ook 4 uurs support, en dat houd niet in dat ze het binnen 4 uur oplossen, maar dat ze binnen 4 uur beginnen met het bedenken van een oplossing ;)

Zou leuk zijn, rebuild duurt namelijk ~5 uur, meteen over de 4 uur heen! ;)

Maar ze verdenken heel erg hard de verouderde firmware die we hebben, en die willen ze heel graag updaten, maar ill be damned als ik dat ga doen voordat ik er een backup van heb en tweakers weer beter werkt.
Ai :/ . Onze 4 uurs support is iets anders ingeregeld. Ze hebben 1 uur de tijd om via de telefoon het probleem te herkennen en evt. te verhelpen als dat lukt. Zo niet hebben ze 3 uur om langs te komen en het probleem op te lossen.

Hier valt wel het vervangen van groote stukken hardware buiten zoals de gehele DAS of Server en ook de re-build van de array (wat redelijk logisch is). Maar het vervangen van geheugen, processoren, hardschijven of controlers valt er wel onder.

De ondersteuningskosten zijn dan ook redelijk hoog. :X

Maar als het probleem onderkent is ben ik heel benieuwd wat de oorzaak is van het niet automatisch herbouwen van de array met de hotspare. Dit ter voorkoming van ooit evt. mogelijke problemen bij ons. Hoewel we hier niet vanuit gaan gezien de erg hooge kosten van de DAS.
dan nog, je mag nooit een SPOF de schuld geven van downtime, never, ben je zelf bij.
Helaas is het verwijderen van SPOF's niet altijd technisch, praktisch of financieel haalbaar of je hebt er wellicht de tijd nog niet voor kunnen vinden (in dit geval is het vooral optie 3).
Ik zie jouw stelling dan ook een stuk minder zwart-wit, in een wereld met ongelimiteerde resources heb je misschien gelijk, maar in de echte wereld...
Die resources bestaan in de echte wereld.

Beter 2 mindere machines die je verwachte load aan kunnen dan 1 SPOF.

Maarja, dat is achteraf praten (voor jullie) :)

En tijd ? Tja... dacht dat er bij tweakers toch heel wat bedrijven betaalden voor zaken. De tijd van Tweakers is over na de overname, jullie zijn een bedrijf met winstoogmerk nu, dus als je ziek bent.... dan heb je daar een collega voor ;)


@ Reflian; dus jij wil je TTL op 1 uur zetten om het binnen de Dell tijden op te lossen :9

[Reactie gewijzigd door RutgerM op 20 januari 2010 02:41]

Helaas hadden we voor dat we deze iSCSI-machine aanschaften nog veel ergere problemen met nfs. Dus toen wilden we toch maar overstappen op een platform dat fail-fast biedt, waar nfs je clients vele seconden laat hangen...
Helaas bleek OCFS2 (en wellicht het verouderde firmware van de MD3000i daarbij) ons niet echt een heel stabiel storage-platform te bieden, maar ook dat is achteraf praat.

We hebben het nu niet over een hele dure machine, twee goedkopere die iSCSI net zo betrouwbaar (nouja...) aanboden als deze zou behoorlijk lastig zijn geweest, vziw was 2 jaar geleden het hele software-iscsi "server" gebeuren voor Linux niet heel erg stabiel.

Een high-available opstelling van NFS was toen (en vziw nog steeds niet?) ook geen heel handig werkende oplossingen. De fail-over tijden zijn daar alsnog vaak in de minuten, terwijl voor webservers je hooguit over n seconde zou mogen praten.

We zijn overigens niet "een bedrijf met winstoogmerk nu", ik kan me niet herinneren dat we dat in 2002 (toen ik mijn contract tekende) dat niet waren hoor ;)
Maar dan nog is tijd een schaarse resource, het is niet alsof we nooit naar redundante oplossingen voor de storage hebben gekeken, maar het is wel zo dat we nooit een oplossing hebben gevonden die echt goed leek te werken voor ons doel... En helaas is het altijd lastig je productiebelasting in een testomgeving te krijgen (zeker als je geen budget hebt om letterlijk alles dubbel te kopen), dus kom je er vaak achteraf pas achter dat iets niet goed werkt, of moet je vooraf gewoon veel kritischer zijn en daarmee een mogelijke oplossing misschien ten onrechte afkeuren.
Dus toen hebben we 2 jaar geleden maar voor een ogenschijnlijk stabiele "SPOF"-oplossing gekozen en nu weer (maar wel een andere). Hoewel we uiteraard blijven kijken naar manieren om iig een warm- of coldstandby te hanteren.

Kortom, een SPOF oplossen is vziw nog altijd niet zo makkelijk.
Hmm volgens mij heb je me toch verkeerd ingeschat, ik weet heel goed dat jullie velen servers hebben, en juist om die reden kwam ik met mijn opmerking. Het feit dat je een SPOF in je situatie hebt hoeft niet slecht te zijn, zolang deze stabiel is. Waar je dan wel op moet letten is dat de downtime geen vele uren bedraagt op het moment dat deze eruit klapt. Dit is erg makkelijk op te lossen. Zoals je zei weinig gigabytes, dit houdt in dat je makkelijk een kopie van de data ergens in takt zou kunnen houden, ook al is dit geen 100% live variant. Misschien is DNS inderdaad niet de oplossing om te wisselen op zo'n moment (ik was erg moe op het moment ;-) ), maar alleen al een PHP variabele voor de locatie van de fotos zou zeer makkelijk te maken moeten zijn, waarbij je dan alleen die variabele hoeft te veranderen zodra je img server down gaat, en een van de andere servers de load overneemt, ik neem aan dat je met een beetje fantasie iets moois zou moeten kunnen maken en daarmee een redelijke frontpage tot gevolg, en een complete.

Dit is bijv ook een reden waarom je zou kunnen gaan virtualiseren, op je SQL server na dan.

Waar ik vooral op doel, is dat bij web snelheid altijd hoog in het vaandel staat, maar data niet reusachtig is. Als je bijv. 2 grote SAN's zou nemen die beide de load zouden kunnen dragen maar wel met hoge belasting, vervolgens de data op beide identiek houd maar de load splitst, heb je een situatie waarbij bij uitval van 1 van de SAN's (redundant als ze zijn, het gebeurd) altijd op de 2e kan werken totdat de 1e geholpen is. Dit kan eigenlijk op ieder niveau.

[Reactie gewijzigd door Reflian op 20 januari 2010 19:07]

Wat dacht je van een data-mirror met de webserver van het t.net domein, en andersom, de data was niet enorm groot, geeft tweakers zelf aan. Als je de data redelijk gesynchroniseerd houdt, is er bij uitval alleen een DNS wijziging nodig en is de website hooguit wat zwaarder belast, kan men in de achtergrond verder met het oplossen van het probleem... misschien een tip voor de toekomst?

edit: Alleen al zou het een selectie zijn voor de meest recente data, is het hinder voor de meeste gebruikers veel minder.

[Reactie gewijzigd door Reflian op 20 januari 2010 00:31]

Dit probleem speelde op een heel ander niveau binnen ons servernetwerk. We hebben niet, zoals je lijkt te denken, slechts 1 server... We hebben er in totaal iets van 16.

En zoals je kon merken werkt de site an sich nog behoorlijk goed, zij het dat ie wat kaler was dan normaal. Met DNS klooien is overigens een van de beroerdste manieren om een redundant netwerk op te bouwen, want er zijn altijd DNS-servers die je (lage) TTL negeren en het is voor normaal gebruik weer helemaal niet handig om een lage TTL te hebben. Kortom, er is dan een hele grote kans dat gedurende de hele dag er nog altijd flink wat bezoekers met de problematische groep servers verbinden.

Overigens heb je dat "niet veel data" verkeerd geintepreteerd. Het is niet veel data in gigabytes gesproken, het is wel veel data in aantal files gemeten.
Kan die controller de raidset niet terug herkennen ?

Je pakt de controller, gooit de raidset weg zonder aangesloten disken, andere disken eraan... flashen en de controller de raidset weer laten zoeken in de oude setup op de oude disken.

Nu kan je het probleem hebben dat hij geen faulty set kan terug herkennen, maar opzich zou dat geen probleem op moeten leveren.

Je kan dit prima doen als je een backup hebt, hence waarom hebben jullie geen drbd slave in godnaam voor dit soort data ? De investering tov van de kosten welke je nu eigenlijk hebt zijn nihil namelijk.
Hebben jullie de servers voorzien van SSD's of spinning weels ?

Succes :)
vast niet, - - ssd's, zijn nogal prijzig...

@kees, ja die optie had ik er ook bij moeten zetten,
enkel ssd's gebruiken is als ik jullie eigen revieuws mag geloven nog niet eg haalbaar,
maar voor die cash is het natuulijk wel heel prettig, - al moet ik bekennen dat ik dit soort spul nog nooit in actie heb mogen zien (in combinatie met zfs of soort gelijke filesystems),

ik zou dus wel heel geintresseerd zijn in revieuws van zulk spul,

om eerlijk te zijn, zou ik per definitie wel geintresseerd zijn in veel meer leesvoer op zulk gebied,

eigenlijk raar, want jullie schrijven al rapporten (reviews) en bakken benchmarks (mag ik aannemen) voor intern gebruik, dus eigenlijk is dan het halve werk al gedaan, en kan de stap naar een publicatie toch niet zo heel groot meer zijn...

in plaats daarvan wordt er veel meer focus gelegd op de 13 in een dozijns >300$ gsmmetjes,
iets waar je na de 5e revieuw ook wel genoeg van hebt ... kortom gun ons eens wat meer technisch leesvoer, (na dat dit is opgelost natuurlijk) ...

[Reactie gewijzigd door i-chat op 19 januari 2010 23:32]

De server die deze gaat vervangen beschikt over 2x80G MLC ssd voor read cache en 2x32G SLC SSD voor write cache. Samen met een stuk of 10 500G schijven om de data op te slaan. ZFS kan erg goed met ssd's in zo'n opstelling omgaan.

[Reactie gewijzigd door ACM op 19 januari 2010 20:03]

Betekent dit dat jullie overgaan op OpenSolaris of gaan jullie FreeBSD gebruiken?
We gaan (deels) over op OpenSolaris ja.
Gistermiddag bleek dat een disk van de raid5-array van Athos als 'failed' gezien werd. Helaas weigerde de controller echter om de reserveschijf (blijvend) in gebruik te nemen en ook een nieuwe disk wordt door Athos structureel genegeerd.
Hmmm... en ik die dacht dat raid5 zo-goed-als-onfeilbaar was. Hiermee wordt bewezen dat niets onfeilbaar is of alles dan toch feilbaar.
eigenlijk zou het artikel op Wiki.en:RAID5 mogen aangepast worden met deze informatie, want het volgende gaat in dit geval niet op.
... until the failed drive has been replaced and rebuilt
Ik neem aan dat dit probleem wel heel uitzonderlijk is ... de vervangen schijf wordt niet aanvaard ..
Nou, veel succes om dit uitzonderlijk geval op te lossen .. jullie hebben mijn mentale steun ;)
Uiteraard ben ik ook wel benieuwd wat het feitelijke probleem is/was en zeker de oplossing,
is het nu een "falende raid controller" zoals hierboven wel eens gesuggereerd werd of is het iets anders? of een opstapeling van "kleine Murphy's"
time will tell
succes!

edit: ok replacede AND rebuild --> dan toch correct ;)

[Reactie gewijzigd door Psqad op 19 januari 2010 22:37]

Nadeel van RAID6 is natuurlijk ook dat als je allemaal schijven uit de zelfde productie batch gebruikt, en er is iets mis mee, is de kans groot dat ze allemaal in de zelfde tijdsperiode falen. Met RAID5 en twee hotspares heb je dit probleem minder omdat de hotspares niet slijten omdat ze uit staan. Natuurlijk geeft het nog steeds problemen als de schijven zo snel achter elkaar falen dat de hotspare niet "herbouwd" kan worden. Eigenlijk zijn RAID5/6 beide niet echt betrouwbaar om die reden. Zelf zou ik RAID1 gebruiken voor zo'n toepassing. Maarja ik heb dan totaal geen ervaring met websites en servers.
Raid 6 kan je ook nog gewoon hotspares aan toevoegen hoor, t'word er alleen amar veiliger op ...
Onzin, schijven toevoegen en verwijderen werkt hetzelfde als bij raid5. Het enige probleem wat je bij zo'n beetje elke raidoplossing hebt is dat de nieuwe schijven niet kleiner mogen zijn da de schijf die je verwijderd, helaas is 200G niet altijd 200G maar kan het wat bytes schelen. Maar dat is weer eenvoudig op te lossen door iets grotere schijven te gebruiken als je niet exact hetzelfde type kan vinden.
Grote vraag, waarom geen Raid6?
da's geen grote vraag, als de device geen hotspare goed oppikt met RAID5, zal hij bij RAID6 ook stom gaan doen. In beide gevallen zou hij hetzelfde gedrag hebben vertoont, namelijk zinloze reboots. (waarbij ik even wil opmerken dat ik niet zeker weet of die ding wel raid6 ondersteund ;) )
Zeer vervelend, hoop dat dit snel opgelost is
Anders ga je toch je geld terugvragen? Oh wacht.. :X
Als Tweakers loopt te baggeren begin ik altijd te twijfelen of m'n internetverbinding nog wel up is. Maar andere pagina's opende wel gewoon normaal. Achja, suc6 met het oplossen :). Vervelen de systeembeheerders zich iig niet! :P
Haha, hier juist hetzelfde. Tweakers laadt altijd razendsnel, dus ik dacht onmiddellijk dat het wr m'n crappy internetverbinding is :)

Good luck ;)
Ik dacht ook dat m'n router/modem die de laatste tijd kuren heeft het veroorzaakt. Ik dat ding resetten, maar niks hielp. Toen toch maar ff verder gekeken of het niet bij tweakers zat en .Plans gecheckt en inderdaad zat toch bij tweakers.
Alles was de laatste tijd zo stabiel hier dat ik het ook echt niet verwachtte.

Succes met het oplossen en maak je eigen niet te druk ;)
Hehe, ik dacht ook al, wat is het opeens traag. M'n internet kan het niet zijn, dan zou ook de internet radio die ik aan heb moeten stoppen. Toen zowel de FP als GoT traag gingen (< 1 KB/s), en andere sites wel snel, had ik al gelijk door dat het bij T.net lag, helaas.

Succes mensen, een gare RAID controller is nooit leuk.
zo dat is balen een RAID 5 met hotspare en dan nog niet werken. Heb het helaas zelf 1 keer gehad. Niet met een MD3000(i) maar met een PE2850 6 disks, waarvan 1 hotspare.......en ho maar dat die ging werken.

Floep server onderuit. Tsja en dan wordt je best druk als je Exchange erop staat. Tape erin en restoren maar.

Ik leef met jullie mee! succes!

[Reactie gewijzigd door loodgieter op 19 januari 2010 22:40]

Het werkt wel, maar niet al te lang. Zodra de bak reset reset ocfs2 de servers. Er is geen data verloren gegaan, maar het terughalen duurt wel wat langer als je elke keer overnieuw moet beginnen omdat een server reset.
Op dit moment heb ik er totaal geen last meer van. Alle plaatjes die eerst dood waren, worden nu netjes getoond, waar ik ook kom op de website.
De tijdelijke oplossing in de lucht gegaan?
sort of ja, moet nog wel wat files kopieren enzo
Volgens mij werkt de updater van de forum reacties niet emer, hij geeft geen tijd meer maar de datum, trouwens de karma grafieken zijn ook weer gefixed.
Klopt helemaal, hier ook. Er staan nu alleen maar forumberichten van gisteren in de tracker. Cookies deleten helpt ook niet.

Edit: Fixed! Al dat harde werk heeft wel resultaat, keep it up!

[Reactie gewijzigd door Rossi op 20 januari 2010 09:43]

En idem voor de RSS-feed van V&A. De laatste is alweer van gistermorgen voor 7 uur.

edit: Hij is gefixt! idem voor de forumberichten.

[Reactie gewijzigd door Snowmiss op 20 januari 2010 09:26]

1 2 3 ... 6

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True