Nieuwe fileserver in gebruik genomen

"Het zal de vaste Tweakers.net-bezoeker niet ontgaan zijn dat t.net als gevolg van een instabiele fileserver zo af en toe niet bereikbaar is."

Zo begon op 16 juni 2003 een .plan over de zoveelste nieuwe fileserver. En die inleiding konden we eigenlijk voor bijna elke mededeling over fileservers wel gebruiken. Sterker nog, we hebben tot nu toe nog maar één fileserver vervangen omdat de machine daadwerkelijk afgeschreven was.

We begonnen met de eerste Atlas, een machine van Gigabyte die niet stabiel bleek. Deze ging na een tijdje terug naar de fabrikant en uit Femme's reactie blijkt wel dat de toen tijdelijke vervanger ook niet zo denderend werkte. Van True mochten we toen gebruik maken van hun netapp. Maar ook dat ging niet helemaal van een leien dakje.

Om die tijdelijke oplossing te vervangen werd ons door een sponsor een Compaq ML530 geleverd. Maar ook deze machine bleek weer last te hebben van diverse problemen; bepaalde scsi-bays konden niet gebruikt worden en van de ide-disks kon de middelste niet gebruikt worden in verband met de warmte. Uiteindelijk is ook deze machine geregeld teruggekeerd in de statusmeldingen.

Gigabyte GS-SR202 en Compaq ML530

Nadat de Compaq door de nodige aanpassingen redelijk stabiel liep werd deze uiteindelijk te langzaam om zowel files als searches te verwerken en hebben we het model opgesplitst in twee machines. Achteraf gezien was dit onze enige stabiele Atlas tot nu toe. De Melrow-Atlas was op een gegeven moment afgeschreven en die hebben we toen vervangen door een systeem met wat meer schijfruimte.

We kregen een leuke deal voor een IBM x3650. En je raad het al, die was niet stabiel. De stabiele Melrow-Atlas hing gelukkig ook nog in het rack en die is toen maar weer ingezet. De IBM was op een gegeven moment dusdanig stuk dat we hem als een verloren zaak beschouwden, maar na enkele dagen werkzaamheden door de supportdienst slaagden we er in het geval te reanimeren. Inmiddels draait de IBM alweer een tijdje in ons rack als virtualisatieplatform.

Omdat nfs onaangenaam gedrag vertoonde op momenten dat de server eruit lag (en dat gebeurde vrij vaak) wilden we liever wat anders. Het probleem met nfs is namelijk dat het 'heel lang' duurt (standaard meer dan een seconde) voor een call een timeout krijgt. En dat is voor web-taken veel te lang, binnen no-time zitten alle beschikbare Apache-processen te wachten tot het bestandssysteem weer reageert, in plaats van echt werk te doen.

IBM x3650 en Dell MD3000i

Een van de oplossingen leek een san met daarop een cluster filesystem. De betaalbare hardwarematige iscsi-oplossingen waren toen interessant geworden en we stapten over op een MD3000i met daarop ocfs2. Nouja, dit is allemaal recente geschiedenis... De MD3000i bleek - naar we nu weten - af en toe alle verbindingen dicht te gooien en daarna weer verder te gaan. Daar kon vervolgens ocfs2 heel slecht tegen en het systeem vond daarna dat de bijbehorende servers maar moesten rebooten. Uiteindelijk bleek dat er nog een goede reden was om de firmware up to date te houden; nadat een disk stuk ging weigerde de MD3000i zijn raid te rebuilden met de aanwezige hotspare.

Aangezien we toch de voorkeur gaven aan wat minder rigoreuze foutbestrijding - bij het minste of geringste al rebooten is wat ruig - zijn we voor dat laatste probleem al aan de slag gegaan met weer een nieuwe nfs-server. Dit keer viel de keus op een systeem dat leek op Suns open storage platform. De nieuwe server bestaat uit een Sun Fire x4270 met daarop OpenSolaris dat gebruik maakt van het zfs-filesystem. Het is tegelijk ons eerste systeem met 'software'-raid.

Sun Fire x4270 specs
Processor	2x Intel E5520
Geheugen	6x 1066Mhz 4GB, 24GB in totaal
Bootdisks	2x 2.5" 146GB 10k rpm SAS
Opslagdisks	10x 2.5" 500GB 7.2k rpm SATA RAIDZ2
ZFS L2ARC	2x Intel X25-M 80GB ssd striped
ZFS slog	2x Intel X25-E 32GB ssd mirrored

Het zfs-bestandssysteem slaat alle data permanent op de dubbel redundante array van 500GB sata-disks op. Maar omdat die niet super snel zijn, maakt het gebruik van de twee X25-E's om het schrijven van data te versnellen en de X25-M's om in totaal bovenop de 24GB ram nog eens 160GB extra cache-ruimte te bieden. Dit nieuwe systeem verdeelt zijn data weer ouderwets met nfs. In verband met de beheersbaarheidfeatures, zoals snapshots en losse datasets, van zfs te combineren met nog een beetje extra performance wilden we graag nfs4 gebruiken.

En je raadt het al... Het is blijkbaar, ondanks jaren van ontwikkeling, niet stabiel. De downtimes van de afgelopen week waren aan deze instabiliteit te wijten De precieze oorzaak weten we niet, maar zowel de Linux-clients als de OpenSolaris-server lijken moeite te hebben om nfs4 op een fatsoenlijke manier aan te bieden en te gebruiken. Vandaag zullen we dan ook terug gaan naar nfs3 en verwachten we dan eindelijk een stabiel shared filesystem aan te kunnen bieden. De vervolgstap wordt dan om met zfs' replicatie-functionaliteit ook een tweede server in te richten met dezelfde data. Vanaf dat moment zouden we ook de uitval van de primaire fileserver snel op moeten kunnen vangen.

Reacties (62)

[creator1988]

En redundantie naar de cloud toe? Toen de EMC bij ons omviel zijn we overgeschakeld naar een mirror die op S3 stond, en dat heeft geen problemen tot gevolg gehad.

We draaien ~6x zoveel pageviews als jullie, en ik denk dat we gemiddeld per pageview meer media serveren.

[ACM]

En wat voor latencies levert dat op? Hoeveel files hebben jullie er op staan, wat kost zoiets aan bandbreedte op de momenten dat je juist je bandbreedte al nodig hebt?

Juist de files die wij nu nog rechtstreeks eraf halen zorgen ervoor dat we af en toe fors wat data verkeer moeten doen, zoals video-files. De rest komt toch bijna altijd wel van lokale disk-caches.

Bovendien, de mirroring is hier nog niet eens het probleem... Het gaat al om de primaire data-opslag.

[creator1988]

De primaire dataopslag losten wij op door een tijdelijke share op te zetten waarnaar we onze writes deden, deze syncte vervolgens naar S3 waar de media beschikbaar werd.

Latency viel ontzettend mee; trager dan normaal, maar acceptabel. We serveren nu sowieso al vanwege de kosten een deel van onze primaire content via S3 (vnl. de grotere foto's). We serven zo'n 100 Mbps, op piekmomenten meer.

[ACM]

Ahja, als je S3 direct als CDN gebruikt is het alweer wat anders, dan wanneer je de files eerst weer naar je data-center moet halen om ze dan aan de gebruiker te geven.

Nadeel voor ons is natuurlijk dat we voor ons eigen dataverkeer nog steeds niet zoveel hoeven te betalen. Dus elke hosted solution buiten ons rack is automatisch duurder op het gebied van dataverkeer. Of dan de totale beheers- en aanschafkosten opwegen tegen de gebruikskosten van zo'n service is dan nog steeds het bekijken waard, maar zal allicht sneller negatief uitvallen dan voor jullie.

[Skinkie]

@ACM zoals we ook al gemaild hadden. Waarom draaien de bestanden niet via een webserver naar de edge webservers, maar via NFS?

[ACM]

We hebben niet alleen maar gedeelde files die naar gebruikers gaan. Ook diverse scripts die op een of meerdere servers uitgevoerd worden, home-directories etc.

Ongeacht wat we voor de web-files kiezen hebben we hoe-dan-ook een stabiel gedeeld filesystem nodig...

Overigens zijn voor sommige gedeelde files wat meer checks nodig dan domweg een 'bestaat ie?' Zodat verplicht een oplossing nemen met een reverse proxy ook niet altijd ideaal is.

[Reactie gewijzigd door ACM op 25 juli 2024 11:30]

[Skinkie]

Oh laat het duidelijk zijn dat ik het zeker met je eens ben dat je iig iets nodig hebt dat netwerk storage biedt. Maar ik zou me zo goed kunnen voorstellen dat je heel wat gezeik minder hebt dat als 'statische' bestanden, die toch altijd statisch zijn, wel via een reverse proxy draait.

[moto-moi]

statische bestanden, zoals de php files, staan al jaren lokaal, maar aangezien er redelijk wat plaatjes verspreidt over de site staan, de fpa's, de usericons, die we toch van nfs af moeten halen, hebben we toch echt centrale storage nodig

[ACM]

Met de toevoeging dat de plaatjes waar geen ingewikkelde checks voor nodig allemaal in principe al via reverse proxies worden geservereerd.

Er zijn maar heel weinig zaken die echt nog van de nfs-share geladen worden. De diverse video-files zijn eigenlijk de enige die een beetje data trekken. Vandaar ook dat de instabiliteit ons zo verbaasde en we er extra van balen

[Skinkie]

Ik denk dat je het punt mist moto-moi, mijn suggestie aan ACM was om op de fileserver zelf een webserver te draaien, die juist die usericons etc. serveert. Daar hang je dan een reverseproxy voor wat connectie management.

Dus in plaats dat je edge op je NFS zit te zuigen, haal je dat via HTTP op. Overhead daarvan is miniem, en vooral: degelijk.

[geez]

Is een alternatief voor NFS geen optie, zoals AFS? Hebben jullie al getest met dergelijke alternatieven?

edit: Waarom niet? Wat me zo voor de hand lijkt te liggen is dat AFS zich nog niet bewezen heeft?

[Reactie gewijzigd door geez op 25 juli 2024 11:30]

[Skinkie]

AFS is echt geen optie

[Verwijderd]

waarom gebruiken jullie geen iSCSI (bijv. Equallogic) of Fiber attached SAN ?
met de multipath deamon van linux en/of windows kan je dat heel goed load balancen en fault tolerant maken...

[Reactie gewijzigd door Verwijderd op 25 juli 2024 11:30]

[voodooless]

Je zit nog steeds met je filesysteem. Zolang er geen degelijk en betrouwbaar fs is, zit je aan NFS vast, no matter wat je er voor storage aan hangt.

[Verwijderd]

dat is waar, de keuze voor het filesystem is belangrijk
maar je hebt in principe geen NFS (server) nodig om storage te sharen, dat kan je gewoon toewijzen aan alle servers die de storage nodig hebben...

[Kees]

Daar komen we juist vanaf; een iscsi oplossing die een disk uitgaf aan de webservers, die er vervolgens met ocfs2 op schreven. Maar dan heb je een aantal zeer grote nadelen:

- Als er 1 server uitklapt, zal de rest gelocked zijn tot er lockrecovery is gedaan, als dat niet goed gaat (gebeurd altijd wel een paar keer) dan kun je random servers gaan rebooten tot lock recorvery op een van hen begint
- Als het gelocked is is het lang niet altijd duidelijk waardoor het komt
- Als het gelocked is, dan mag je er zelfs readonly niet bijkomen (why not?)
- Als bv je connectie naar de iscsi gereset wordt doordat de firmware van dat ding steeds brakker wordt (echt, wtf) dan gaan de servers elkaar fencen (GFS) of fencen ze zichzelf (OCFS2)
- Een disk unmounten nadat hij een lange tijd gemount is kan gruwelijk lang duren, 15 minuten is geen uitzondering.
- En vrijwel elke cluster implementatie zuigt, er is gewoon geen goed FS voor een 'read most, write once in a while'.

Kortom, een cluster filesystem kan een SPOF (single point of failure) vervangen, maar dan vervang je hem wel met een MPOF (multiple points of failure).

Op zich is het idee achter iscsi prima, echter kleven er aan het filesystem nogal wat bezwaren. Je kan niet zomaar ext3 gebruiken, want die heeft niet door als iemand anders erop schrijft, zelfs niet als je hem readonly mount en maar 1 server laat schrijven, dus heb je een cluster aware filesystem nodig, en die zijn momenteel niet bijzonder geschikt voor het simpele werk.

[Verwijderd]

Je bedoelt eigenlijk dat je een FS nodig hebt dat concurrent access toelaat zonder helemaal in het honderd te lopen. De boel volledig readonly met noatime mounten zou mogelijk kunnen werken, maar je wilt ooit wel een keer filtjes weg willen schrijven

[Verwijderd]

VMFS denk ik dan.... Maar dat is alleen geschikt om Vm's op te draaien. Clusteren onder VMware is trouwens ook niet het sterkste punt......(tenzij VMware zelf clustert)

Dit is inderdaad wel een lastig probleem.

[Stewie!]

Zoveel hardware platformen, zoveel wisselingen in achterliggende systemen.
Zijn al die technologieen nou brak of zijn de twiekers iets te veeleisend

[ACM]

De eerste paar systemen hadden inderdaad hardware-failures. Kapotte moederborden, diskbays die niet goed werkten, etc etc.

De laatste, de MD3000i was eigenlijk meer een software-probleem, in de zin dat we wat firmware-updates achter liepen. En het nieuwste systeem, de x4270, is voor zover we kunnen nagaan ook gewoon stabiel. Maar daar doet de software moeilijk.

[siepeltjuh]

Maar je gaat nu dus weer terug naar NFS met de 1 seconden timeouts?

Doet dat als de fileserver down gaat er dan niet voor zorgen dat Apache een DOS te verwerken krijgt en alle webservers dus ook down trekt.

Liever t.net zonder plaatjes dan helemaal geen t.net

[ACM]

Ondertussen hebben we sowieso meer maatregelen genomen tegen die situatie, o.a. door te werken met Varnish als reverse proxy zodat voor de meeste requests voor afbeeldingen uberhaupt geen contact meer wordt gezocht met NFS.

Bovendien had OCFS2 dus als fout-oplossing om servers te reboten... En dat levert nog meer down time op dan een apache die niet helemaal goed bereikbaar meer is. Overigens zijn de timeouts nog wel iets korter gezet, hoewel nog steeds 'lang' in web-termen

[Reactie gewijzigd door ACM op 25 juli 2024 11:30]

[_JGC_]

Een tijdje terug kwam ik FSCache tegen als kernel optie, geen idee of jullie dit inderdaad al onderzocht hebben, maar afhankelijk van testresultaten kan het erg nuttig zijn:
http://www.linux-mag.com/id/7378/1/

Ik wil er binnenkort zelf eens mee gaan testen, als het goed werkt denk ik dat het efficienter is dan wat we nu gebruiken voor het cachen van files.

[ACM]

Dat gaan we inderdaad binnenkort ook nog beter bekijken

[s.stok]

Wat ik zo 123 niet voorbij heb zien komen is Gluster.
Is hier al naar gekeken?

[ACM]

De vorige keer dat we naar een shared omgeving keken was Gluster net uit. Nu heb ik er onlangs wel weer naar gekeken, maar ik geloof dat er nog steeds wel wat onhandigheden in zitten.
Ik moet wel zeggen dat ik zo gauw niet meer uit mijn hoofd weten wat die punten waren Ik geloof dat het vooral ook weer ivm de video-files minder geschikt leek.

[bartvb]

Super dat Tweakers ons op de hoogte houdt van de ontwikkelingen achter de schermen, allemaal erg informatief en het zorg er vooral voor dat wij dezelfde 'fouten' maken.

GlusterFS is iets waar wij op dit moment naar aan het kijken zijn. Gebruiken nu NFS maar sjiez, wat is dat een achterhaald bagger systeem. GlusterFS ziet er tot nu toe erg goed uit, vrij eenvoudig in setup, ingebouwde replicatie, ingebouwde failover, ingebouwde striping. Lijkt erop dat het ook prima te gebruiken is voor het streamen van grote videofiles.

[CyBeR]

Ik gebruik gluster over twee nodes heen met daarop data die vroeger als blob in onze mysql stond. Alles van pdf's tot plaatjes tot video's dus. Dat is eigenlijk al sinds ik 't met FUSE gebruik nog geen een keer kapot gegaan, dus ik ben er prima tevreden over. Ik heb 't ook een tijdje zonder FUSE gebruikt maar dat ging af en toe wel kapot omdat je app's fs-operaties dan omgeleid worden naar gluster (met de bedoeling hogere performance te bieden).

Dat Gluster in de achtergrond je files kwijt kan op een gewoon POSIX fs is ook een pluspunt imo. Mocht 't dan toch kapot gaan, zit je niet met een enorme blob aan data waar je niets meer mee kan maar kun je gewoon direct je data uit 't backend-fs halen.

[Cergorach]

Als video files zo een probleem zijn, waarom gebruiken jullie dan geen dedicated dienst daarvoor en embedden de video files op die manier? YouTube wordt vrij veel gebruikt en je zou op die manier ook mensen kunnen trekken naar tweakers.net die aan het zoeken zijn op YouTube. Scheelt ook meteen in bandbreedte...

[ACM]

Ze zijn helemaal geen probleem Alleen vormen ze wel mede een belemmering om allerlei exotische cluster toepassingen te gebruiken.

De bandbreedte maakt ons verder niet zo uit. We vinden het wel wat vreemd om youtube's gebeuren steeds te integreren, vooral omdat we dan ook niet meer weten wat er aan reclames gepre-rolled kan gaan worden enzo.

[webkiller71]

Al MogileFS overwogen? Er is ook een nginx module om het direct vanuit de webserver aan te bieden.

[ACM]

MogileFS is niet echt een file-system. Het is meer een http-laag rond een verspreide opslag van files, dus het zou maar voor een deel van de toepassingen die we ervoor hebben bruikbaar zijn. Maar hoe ik het niet zelf getest hebt lijkt bijvoorbeeld video-streaming me geen toepassing die met MogileFS gefaciliteerd kan worden.

Daarnaast gelden ook daarvoor de eerder door mij aangehaalde requirements dat we hoe-dan-ook toch wel een gedeeld file-system nodig hebben met onze huidige opstelling.

[bartvb]

Er zijn redelijk wat sites die MogileFS gebruiken voor videostreaming. Grootste nadeel van MobileFS is dat het nogal flinke aanpassingen van je applicatie vereist of je moet de Fuse client flink verbeteren. Deze laatste bestaat wel maar is op dit moment niet heel erg stabiel.

Idee achter MogileFS is op zich erg leuk, performance schijnt alleen niet heel erg super te zijn en het feit dat het geen 'normaal' filesystem is, is best een nadeel.

Overigens een interessante ontwikkeling:

http://www.facebook.com/note.php?note_id=76191543919

Hoorde op Fosdem dat ze dit ook gaan opensourcen binnenkort. Als je voor performance gaat dan is dit zo ongeveer de heilige graal op dit moment

[webkiller71]

Ik moet toegeven dat ik het nog niet geprobeerd heb buiten een paar kleine testjes, zou het voor user icons en fotos (waar het bij livejournal ook voor ontwikkeld is) je wel kunnen helpen.

De reden dat ik geinteresseerd ben, is dat wij ook af en toe problemen hebben met onze iSCSI en ook alternatieven overwegen.

[Aike]

Dit is dus een 'gewone' server van Sun waar je zelf vanalles op installeerd? Waarom geen machine uit de 7000 serie dan? Daar staat alles al op en krijg je ook nog eens software updates en support.

[ACM]

Software updates krijgen we nu natuurlijk ook, opensolaris is tenslotte gratis/vrij te gebruiken. Wat we vooral missen is die hippe grafische webinterface van ze.

En die support moet je vrij aardig voor in de buidel tasten. We hebben nou eenmaal niet echt onbeperkte middelen en als je dan voor een 7110 met dezelfde bruto opslag (16x300GB sas) dan uiteindelijk 2x zoveel betaald als hiervoor... Dan is het puntje support niet automatisch doorslaggevend meer om voor minder performance en minder flexibiliteit (we kunnen nu bijv direct een rsync-daemon files naar linux trekken ipv via nfs en dan zelf kijken wat er gewijzigd is met rsync) te kiezen.

[vargo]

Neem aan dat je met de webinterface de ZFS web ui bedoelt?
Schijnt met een handmatige install wel te kunnen werken onder OpenSolaris.

[arjankoole]

Tja, voor shared storage kom je eigelijk haast niet om NFS heen, alhoewel dat soms een klein beetje een pain in the rear is. Ze zouden daar nog eens een goeie cluster variant van moeten verzinnen. Hebben jullie wel eens naar GFS2 gekeken? ( van redhat, maar wel opensource IIRC)

[Kees]

Ja, laatste keer dat ik er naar keek had redhat ongetest een update gedaan richting de vanilla kernel, en uiteraard gebruikte ik die kernel met de bewuste update, met als gevolg dat elke file groter dan 3.2kb ineens 0 bytes groot was, dus gfs2 weggedaan, gfs1 gepakt, maar gfs1 ook snel weggedaan nadat alle servers zonder duidelijke reden gelocked werden.

[arjankoole]

Ja, laatste keer dat ik er naar keek had redhat ongetest een update gedaan richting de vanilla kernel, en uiteraard gebruikte ik die kernel met de bewuste update, met als gevolg dat elke file groter dan 3.2kb ineens 0 bytes groot was, dus gfs2 weggedaan, gfs1 gepakt, maar gfs1 ook snel weggedaan nadat alle servers zonder duidelijke reden gelocked werden.

Jikes, dat is inderdaad meer dan voldoende reden om 't te negeren. Wat een blunder van een fout zeg.

[naftebakje]

Als ik het artikel zo lees, vraag ik me af wat er zal gekozen als tweede server: gaan jullie voor 2 * hetzelfde systeem, of wordt er gekozen voor een andere (zo verschillend mogelijke) backup-fileserver in de hoop dat als het volgende gekke probleem opduikt dit niet op beide systemen zit?

[ACM]

Waarschijnlijk gaan we in ieder geval voorlopig de nog in het rack hangende MD3000i gebruiken voor de opslag van die 2e server en daar dan een dedicated 'head unit' aan hangen. Maar het is iets dat nog niet enorm goed is uitgedacht omdat we al onze aandacht op de primaire shared storage hebben gericht

[Bierkameel]

Misschien tijd om toch maar eens te investeren in iets fatsoenlijks als een EMC CX4-120 en een paar FC HBA's voor in de servers, het kost wat maar dan heb je super performance en al je problemen zijn over.
If you pay peanuts, you get monkeys geld ook voor storage

[ACM]

En vervolgens heb je dan alsnog een cluster file-system nodig, zoals OCFS2, wat niet enorm goed beviel (hoewel mede veroorzaakt door de wankele iscsi-laag eronder)

En 'het kost wat', volgens mij kost het net zoveel als we nu aan ons complete serverpark kwijt zijn...

[Reactie gewijzigd door ACM op 25 juli 2024 11:30]