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.

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.