Server- & netwerkstatusmeldingen IX

Problemen met de servers en de netwerkverbinding van Tweakers.net worden in deze .plan gemeld. De laatste informatie over de serverloads en -uptimes kun je volgen op de statistiekenpagina.

Statusmeldingen

18-01-10 ocfs2 veroorzaakt meer problemen. Vandaag is blijkbaar een van de harde schijven overleden, wat zo te merken voor ergere problemen zorgt dan we tot nog toe van dit iscsi-systeem "gewend" waren. Kees is druk bezig met in ieder geval een firmware-update, die ons door de Dell-supportafdeling is aanbevolen, versneld te installeren. Misschien dat dat wat helpt, morgen krijgen we de nieuwe disk.

18-01-10 Nouja, ocfs2 gaat nu voor de verandering eens niet over de zeik, maar de achterliggende bak, aka, athos, onze iscsi bak. Ben blij dat er atm op kantoor een vervanger ligt waar we mee bezig zijn, dit begint te irritant te worden. Dus alle problemen die je ziet, icoons die niet willen uploaden, missende plaatjes, search die brak is, je weet nu waar je je fanmail heen kan sturen :|

31-12-09 Een klein eindejaarskadootje van OCFS2; servers achter elkaar rebooten omdat het cluster niet lekker werkt. Uiteindelijk deze deathmatch kunnen onderbreken.

18-12-09 Replicatie ging b0rked, dus de rootdisk van Artemis was met een onwijze noodgang aan het vollopen aka, we waren even down ;( Nu maar weer eens zien waarom het deze keer stukkig ging.

27-11-09 Even een MySQL restart. We lopen tegen een zeldzame bug aan, en de 'mensen van mysql' wilden graag wat veranderde settings zien. Bij deze dus.

12-11-09 Tsja, onze ocfs2 gaf weer eens het stokje aan ehm.. niemand. Maar! We zijn inmiddels wel hoopvol dat het zeer snel opgelost kan worden, we zijn al een tijdje aan het testen met een andere oplossing waardoor dit soort problemen hopelijk tot het verleden zullen behoren, want een t.net dat down is, dat kan natuurlijk niet.

30-10-09 Deze nacht zal er kort onderhoud uitgevoerd worden aan de database server. Hierdoor zal de site enkele minuten niet bereikbaar zijn.

update 0:10 We zijn er weer!

15-10-09 Gisteren ging het al niet helemaal tof met Ocfs2, toen we twee servers van rack aan het verplaatsen waren en Ocfs2 besloot dwars te gaan liggen. Ocfs2 is een cluster systeem, en houdt zijn eigen status in de gaten door te kijken hoeveel servers er nog goed werken. Doordat er twee kampen gevormd waren, waarvan elk van de twee vond dat de andere down was, bleek we uiteindelijk een situatie te hebben waar je eigenlijk he-le-maal niets aan hebt, aka downtime. Dat was gelukkig alleen maar tussen de webservers, maar vannacht/vanochtend was het zo erg dat zelfs onze monitoring server het te druk had met zichzelf op te hangen om ons ook maar even een berichtje te sturen. Vandaar dat de downtime wat ongewoon lang was. Nu maar eens iets gaan verzinnen wat beter werkt dan dit systeem, want op dit moment zijn we vaker down dan in de tijd dat we gewoon nog NFS gebruikten, en daarvan vonden we de downtime eigenlijk al vervelend. We'll keep you posted..

25-09-09 Binlogs zijn leuk... maar niet als je harde schijf volloopt omdat je replicatie achter loopt :X En dat legt dan uiteraard je database weer plat.

19-09-09 Aye me mateys, we be back again! Weer een DDoS, ze worden telkens iets groter. Kap nu eens met die onzin.

13-09-09 Vanochtend hebben we weer even plat gelegen vanwege een DDoS, gevolgd door een bokkende fileserver. De DDoS was redelijk snel onder controle, maar het duurde even voordat we opmerkten dat de fileserver om een of andere reden er ook maar mee gestopt was. Afijn, de DDoS loopt nog steeds door, en het kan zijn dat we daardoor af en toe minder goed bereikbaar zijn.

27-05-2009 Blijkbaar heeft ons iSCSI verhaal toch een vervelend staartje. Aangezien we ons serverpark graag up-to-date houden en ook graag nog even semi-live testen, hebben we de server Achelois om ervoor te zorgen dat er nog even getest kan worden, waarna met een script de code/veranderingen online gezet worden. Om dit goed te kunnen doen hebben we ook Achelois in ons iSCSI cluster gegooid. Helaas betreft het een testmachine, dus wil het nog wel eens voorkomen dat Achelois wat minder bereikbaar is. Dit maakt voor het testen an sich weinig uit, maar sinds we iSCSI gebruiken wil Achelois nog wel eens 'eeuh.. ik ben druk, tief op' terug geven naar ocfs, waardoor het cluster over de toeren raakt. We gaan dit uiteraard fixen, maar voorlopig is Tweakers.net weer bereikbaar voor jullie, wat ons net even wat belangrijker leek ;)

30-01-2009 En toen kwam Murphy langs. Voor de piepende server van 24 december (Ate) was ondertussen een vervanging aangeschaft en die ging vandaag het rack in (een .plan met details volgt nog) om komende week geleidelijk aan in gebruik genomen te worden. Tijdens het plaatsen bleek overigens dat er een harde schijf van Apollo stuk was, maar dat zorgde niet voor de problemen van vanmiddag.
Nadat men de colo alweer had verlaten bleek dat Ate weer problemen gaf en zo goed als dood was. Door een wat onhandige poging om Ate te reboten werd per ongeluk een van de vier redundant uitgevoerde netwerkswitches uitgeschakeld. In theorie had dat foutje geen problemen mogen veroorzaken, maar het zorgde er voor dat het interne iSCSI-verkeer zich helemaal in de soep werkte. Daardoor werden de aangesloten servers ruwweg in twee kampen verdeeld die elkaar continu de toegang tot het filesystem op de MD3000i weigerden. Dit zorgde voor meer downtime terwijl het oorspronkelijke probleem al lang en breed was verholpen met dank aan een hulpvaardige medewerker van True die binnen twintig minuten onze switch weer van prik voorzag.
Toch bleven de servers elkaar in de weg zitten, waarna de eenvoudigste oplossing bleek om ze alle zeven tegelijk te reboten... En toen moesten we het probleem met Ate nog oplossen. Dat hebben we uiteindelijk voorlopig maar opgelost door de nieuw geplaatste server direct in te zetten voor de twee belangrijkste taken; memcached en ActiveMQ draaien dus per direct op de nieuwe server.

24-12-2008 Vanwege een piepende server (nooit een goed teken) was voor vanmiddag een extra bezoekje aan de servers ingepland. Om te kunnen onderzoeken waar Ate (de piepende server) precies last van had, moest hij even uit. Nadat hij weer aanging was zijn piep verdwenen, en waar die noodkreet precies voor was, heeft hij ons niet bekend kunnen maken. Helaas waren door het rebooten van Ate het forum en de frontpage even onbereikbaar, maar het zou inmiddels allemaal opgelost moeten zijn en weer als vanouds werken.

15-12-2008 En na nog een aantal crashes hebben we een nieuwe bug in MySQL gevonden die nog niet in oudere versies aanwezig was. De bug is gereport, en de data die het zou kunnen veroorzaken is aangepast. Kortom, de database zou niet meer moeten crashen.

11-12-2008 Zoals sommige bezoekers al hebben gemerkt, ligt de database van het forum af en toe plat. Als dat gebeurt is de database gecrasht, en ging er dus iets fout. Wat er precies fout gaat weten we nog niet en aangezien er bij de laatste update een aantal zaken veranderd zijn, is het lastig uit te vogelen welke update er nu precies voor de problemen zorgt. We houden de database in de gaten en hopen dat deze hiccups van korte duur zijn.

26-10-2008 Na enige tijd met GFS getest te hebben op onze Dell MD3000i hadden we voldoende vertrouwen om een deel van onze files erop te hosten om te zien hoe het voor het eggie draait. Met als uitkomst: het kan opeens vastlopen en al je webservers plat trekken *O* Anyways.. We snappen totaal niet wat er aan de hand is, maar voorlopig staan de files allemaal weer gezellig bij elkaar op Atlas, en ga we volgens een oud gebruik weer terug naar de tekentafel.. Het lijkt erop dat Atlas gewoon niet vervangen wil worden ofzo

9-10-2008 Het is zeldzaam de laatste tijd, maar wij lagen er weer even uit. De reden van de downtime was een 'performance issue' op de routers van onze provider. Gelukkig kon True de oorzaak redelijk snel vinden en oplossen zodat wij je weer van een verse portie Tweakotine kunnen voorzien.

22-06-2008 De mensen die gisteren vroeg huilend in slaap zijn gevallen is het opgevallen, aphrodite (onze zoekmachine) reageerde niet meer vanaf zo'n uur of 3:33. Op de console wat de melding 'rejecting I/O to offline device' te vinden. Wat dus dezelfde melding was als op 3-3 , alleen... weer nergens een reden te vinden waarom, oftewel, we gaan weer zoeken..

16-05-2008 Zoals de hardcore forumbezoekers al wel hebben gemerkt, lag het forum er van 0:50 tot 2:20 uit. De reden was dat de databaseserver van het forum opeens een verschil van mening had met de Apollo-slet. Zoals een echte vrouw betaamt, wilde de Apollo-slet niet meer met de database praten, met als gevolg dat de database gereboot moest worden en op een lang recovery process gewacht moest worden. Op het moment lijkt alles weer te werken, maar we gaan de komende dagen eens erg goed naar deze relatie kijken en zien te achterhalen waarom deze op de klippen liep.

03-03-2008 Iets na 18:00 is Aphrodite, onze searchserver voor zowel het forum als de pricewatch, ermee gestopt, laatste melding die we toegestuurd kregen was:

CRITICAL - load average: 46.17, 34.02, 16.53

Na een inlog op onze kvm kregen we een aantal regels te zien:

sd 0:0:0:0:1 rejecting I/O to offline device

In niet *nix taal: scsi stuk. Op dit moment hebben we net in de raidcontroller gekeken en zijn we erachter dat er volgens de areca kaart niets bijzonders aan de hand is..

18-01-2008 Rond 13:40 vielen we opeens van het internet af. Vrij snel kwamen we erachter dat we niet de enigen waren. Helaas heeft het tot 15:10 moeten duren voordat we weer online waren. Het voorlopige verhaal is dat er 'iets' mis ging bij True, waardoor in eerste instantie True totaal van het internet verdween. Kort hierna kwam Redbus wel online, maar EUNetworks heeft tot 15:10 platgelegen.

Serverstatus (5 minuten vertraagd)

Maart 2007 - December 2007 statusmeldingen VIII

Reacties (326)

Vervelend dat de webservers het GFS onderuit kunnen trekken.

Kan verschillende oorzaken hebben.
- Er zijn zowiezo een aantal GFS tuning parameters die handig zijn om door te voeren.
- Appart netwerk voor het cluster heartbeat.

Ik had een 6 node GFS cluster wat problemen gaf en zeer instabiel was. Na wat enkele paratmeters gezet te hebben ging het een heel stuk beter.

/sbin/gfs_tool settune /gfs/ glock_purge 50
/sbin/gfs_tool settune /gfs/ statfs_slots 128
/sbin/gfs_tool settune /gfs/ demote_secs 200

http://www.open-sharedroot.org/Members/marc/blog/blog-on-gfs <-- meer info en een leuke test.

Je kunt ook nog een constructie maken waarbij je twee machines aansluit Dell MD3000i. Op die twee machines ga je GFS draaien en LVS. LVS voor NFS en dan de NFS share mounten op de systemen waar je het nodig hebt. Oké is wel smerig, maar daarmee trek je niet je GFS onderuit als je webserver(s) problemen heeft.

[Reactie gewijzigd door Beuker op 29 oktober 2008 13:42]

Het grote nadeel van GFS is ook imo dat veel documentatie nogal verstopt staat. Helemaal als je zelf geen redhat draait maar onder debian het aan de praat probeert te krijgen. Het is een behoorlijk stuk gevogel om uit te vinden hoe en waar dingen moeten gebeuren.

En als het eenmaal werkt, en het werkte stabiel voor ruim twee weken, dan verwacht je eigenlijk niet dat het ineens zonder enige melding in de logs crashed. Met crashen bedoel ik dat de lock_dlm de toegang tot de schijf blokkeert en dat alle apache processen in een iowait status terecht komen zodra ze iets van die schijf willen lezen.

Dus ben ik nu maar met ocfs2 begonnen om dit weer te bekijken, een cluster dat 'zomaar' ineens stopt te werken zonder enige melding over wat er nu verkeerd ging kan ik niet gebruiken. Ocfs2 mist op dat gebied ook wel een paar dingen, maar tot nu toe ben ik aangenaam verrast door ocfs2.

Ocfs2 (onder debian) is veel en veel gemakkelijker op te zetten, binnen een paar uur had ik een 2-node cluster draaiende, en ook al had die een paar kleine problemen, de dag erna waren die opgelost (noatime e.d.). De performance van ocfs2 ligt vele malen hoger dan gfs, helemaal als de cache eenmaal gevult is.

Mijn 'perforamance' script haalt een regel uit een bestand (leesactie) met op die regel een plaatje (uit de accesslogs getrokken van een dag). Dat plaatje leest hij vervolgens uit alsof hij hem moet tonen aan een client/browser. Omdat deze dingen veel in de cache gebeuren was dat een van de dingen die ik teste.

Lang verhaal kort: GFS haalde 160 megabyte per seconde, Ocfs2 haalde 300 megabyte per seconde als de cache eenmaal gevult was. NFS haalde in dezelfde testomgeving zo'n 145 megabyte per seconde.

Verder hoef je voor ocfs2 (iig in debian) niet tientallen extra programma's te instaleren en te configureren, en werkt het out of the box allemaal net even wat makkelijker dan gfs. Met gfs had ik ook problemen dat de upstream versie niet goed gecheked was, wat tijdens mijn testing resulteerde in een onmogelijkheid om files groter dan 4kb te maken, server detecteerd dat, inconsistent systeem -> fencing. Ik moest dus mijn kernel downgraden voordat ik weer een werkende gfs module had.

De reden dat ik toch met gfs aan de slag ging was de limieten van ocfs2. Om die limieten kun je heenwerken, maar omdat ik in de initiele vergelijking vrijwel geen verschil vond tussen de twee filesystems ben ik voor gfs gegaan zodat ik me geen zorgen hoef te maken over die limieten. Deze limieten zijn onderhand opgelost en weggewerkt door ACM, dus nu kan ik ocfs2 gaan testen over alle 7 nodes.

Het nadeel van NFS over LVS/GFS is dat je, mocht je gfs er wel uitklappen, alle webservers weer hetzelfde probleem krijgen; namelijk waiting for IO. Nu kun je timeouts e.d. wel heel erg laag zetten (wat ik ook heb) maar dat voorkomt nog steeds niet dat je serverpark in luttele seconden volledig op IO staat te wachten. Ook is de caching van NFS niet je-van-het, met ocfs2 is bijna de enige limiterende factor op dit moment de hoeveelheid geheugen en de snelheid van dat geheugen in de server.

We zullen zien hoe het verder met ocfs2 gaat, mocht ook deze om onverklaarbare redenen ineens stoppen met werken, dan is mijn zoektocht nog niet over

[Reactie gewijzigd door Kees op 30 oktober 2008 13:12]

Het eerste gedrag wat je beschrijft had ik idd ook last van. Twee weken prima daarna crash zonder duidelijke reden.

Je moet eens voor de grap kijken naar het aantal locks dat die heeft.
gfs_tool counters <mountpoint>

Dat loopt namelijk op naarmate het systeem langer draait. Op een gegeven moment komt het op een druk systeem zo hoog dat GFS instabiel wordt. Met de parameters die ik eerder gaf zijn de problemen die ik had opgelost. Wellicht het proberen waard.

Ik moet er wel bij zeggen dat het allemaal draait op Redhat ES 4. Redhat 5 of Centos 5 schijnt een nog nieuwere versie te hebben en stabieler is dan in 4.

Mocht je een keer hulp nodig hebben dan moet je maar roepen hoor.

[Reactie gewijzigd door Beuker op 31 oktober 2008 16:46]

Ocfs2 is inderdaad veel beter dan GFS. Wij gebruiken Ocfs2 in samenwerking met iSCSI (op een Equallogic SAN) en dat is zeer stabiel (op een dedicated storage netwerk uiteraard). De setup zit duidelijk in elkaar en in de praktijk werkt het perfect, ook als nodes uitvallen en later weer terugkomen.

Ik kan het je alleen maar aanraden, wij gebruiken het nu meer dan een half jaar in verschillende loadbalanced setups en tot nu toe nog geen wazige problemen gehad. In een specifieke setup heb ik wel eens problemen gehad met enorm veel kleine files (bijvoorbeeld PHP sessies) dat die dan meer dan 40mbit trekt (over ocfs2, niet iscsi) om het allemaal bij te houden. Wij hebben dat opgelost door de site aan te passen die niet helemaal goed in elkaar zat maar wellicht een idee om daar nog eens mee te testen.

Voor ocfs2 heb ik ook met GFS getest omdat iedereen dat leek te gebruiken toendertijd maar daar heb ik alleen maar slechte ervaringen mee gehad.

Als je specifieke vragen hebt kun je ze gerust stellen via de mail

Wel grappig dat jullie dev server zo'n hoge uptime heeft, die zou je toch wel is willen rebooten lijkt me? *updates gone wrong* enzo

De development server die in ons rack hangt, Achelois, is meer de laatste plek waar we nieuwe code testen, zo draait er een volledige schaduw van het forum en de frontpage.
Updates van bijv. php testen we daar inderdaad ook, maar meestal gaat daar niet zoveel fout

[Reactie gewijzigd door moto-moi op 12 maart 2008 23:01]

Het is dus een test-server, geen dev-server.

Je hebt namelijk vaak een dev, test en prod omgeving.

er wordt ook op gedevved, en om nou moeilijk te gaan doen over exacte benamingen, daar is het miuj nog te vroeg voor

In plaats van GFS kan er ook eens getest worden met OCFS2: http://oss.oracle.com/projects/ocfs2/

Wij draaien er al enkele maanden een 5-koppig webserver cluster op, naar volle tevredenheid. Wellicht is dit een optie?

da's de andere optie inderdaad, kees had die in eerste instantie afgeschoten, ik weer niet meer precies waarom

Omdat het niet overweg kan met meer dan 32k directories in een enkele directorie, verder werkte het prima ja

'An inode can have at most 32000 hard links. This means that a directory is limited to 32000 sub-directories. This limit may be raised when indexed directories are added to the file system.'

En omdat wij een aantal dirs hebben met meer dan 32k directories, is het noodzakelijk om die dan te veranderen.

[Reactie gewijzigd door Kees op 27 oktober 2008 14:38]

Userdirectories?

Ik kan niets anders verzinnen eigenlijk...

32k abonnee's met bestandsruimte lijkt me een beetje veel. Tenzij het abonnee-model van T.net enorm goed werkt

usericons en v&a images, de eerste zit nu op 20k, de tweede op dik 80k subdirs. Maar dat is opzich wel op te lossen. In fact, voor v&a is het al opgelost, dus nu kan ik ocfs2 verder testen (heb het al werkende gehad, maar het enige verschil met gfs was - afgezien dat ocfs2 makkelijker was - de limieten op ocfs2, vandaar dat ik eerst verder keek, en gfs leek erg stabiel.. en dat was het ook, we hebben het maanden getest zonder dat het spontaan crashte, maar nu het voor een klein gedeelte in productie draaide crashte het al redelijk snel spontaan.

We zijn met OCFS2 wel tegen enkele (crash-gevoelige) limieten aan gelopen. Mocht je hier wat meer informatie over willen hebben wil ik die best verstrekken, alleen dan wel graag via email, daar het gaat om wat te gedetailleerde informatie over ons cluster om die zo publiek aan te kaarten.

op truecare is hetvolgende te lezen.

[Solved] Connectivity problems
Around 13:40 CET we started to experience unexplainable connectivity issues between segments of the network. The problems occurred between random source addresses and random destination addresses which made it difficult to find the cause. After thorough investigation we swapped one routing engine on the primary router at the euNetworks facility and brought on a separation between two parts of the network. After these measures the network became more predictable and all sessions were restored. We will keep monitoring the network closely and keep engineers at site for the next few hours. Together with Force10 we will keep investigating to find the exact cause which led to the connectivity issues. We apologise for any inconvenience this issue may have caused. Please do not hestitate to contact our support engineers in case you still experience issues on the network or your machines.

Op dit moment hebben we net in de raidcontroller gekeken en zijn we erachter dat er voglens de areca kaart niets bijzonders aan de hand is..

Arraytje rebuilden en klaar? Of is er toch meer aan de hand?
Overigens moet ik zeggen dat ik er weinig van gemerkt heb, terwijl ik nog in de PW aan het snuffelen was.

Nee, beide array's (root raid1 en data raid5) waren in optimal state.

Toch wel vreemd - hoe kan deze ene server nou zo'n impact hebben op jullie totale site wanneer deze wordt uitgeschakeld? Is het niet een plan om eens de huidige situatie onder de loep te nemen m.b.t het het verbeteren van de redundantie?

Omdat zijn taak (taken) redelijk eenvoudig uit te zetten zijn /naar een andere server over te zetten zijn, door een miscommunicatie is dat deze keer echter iets te laat gebeurd, waardoor de site 2-3 minuten lang foutmeldingen gaf.

En deels omdat er hier gewoon altijd melding van gemaakt wordt, storing van 2-3 minuten wordt door bijna niemand opgemerkt als niemand er iets van zegt

Btw, hij loopt weer te buggen nu.

Kun je ook meer info geven over welke bug?

basically, als hij een nieuwe bin-log opent (hij maakt een nieuwe elke 1.1G) worden alle updates/inserts voor 8-12s geblocked. Dus queries die normaal 0.0001s duren runnen ineens voor 8s.

dat is een gekke bug zeg. hoe vaak loopt een log vol tot 1.1G?

is de aanpassing van instellingen een (mogelijke) fix of een instelling voor het localiseren van de bug?

intressant om over dit soort dingen te lezen.

Het loopt zo'n 30 keer per dag vol anar 1.1G (row based replication). En tja, als er een gemakkelijke fix voor was dat hadden we het al gedaan, ik weet bijna zeker dat het een bug in mysql is, en niet iets wat wij op korte termijn kunnen oplossen.

En heeft de aanpassing geholpen?

Waarom hebben jullie gekozen voor GFS? Ik hoor nogal wat goede dingen van ZFS.

ZFS is geen cluster-aware filesystem maar een lokaal filesysteem.

De specs zijn inderdaad erg leuk, en de theorie erachter is goed, maar als het geen cluster-awareness heeft dan is het niet te gebruiken in een cluster.

Cluster-fs zijn bijvoorbeeld Ocfs2, Lustre en GFS. Als je deze filesystems op meerdere servers mount, en je laat 1 server een nieuwe file aanmaken op dit fs, dan zullen alle andere servers die file kunnen zien (en lezen/schrijven). Als je een non-aware cluster gebruikt dan verwacht de server niet dat er 'zomaar' een file kan verschijnen buiten die server om. Hij zal die file dus niet zien en er ook niet vanuit gaan dat de blocks/inodes die die file in beslag neemt bezet zijn. Een niet-cluster-aware filesystem kun je dus alleen read-only gebruiken, zodra je ook gaat schrijven zal je disk corrupt raken en data gaat verloren, simpelweg omdat ze 'over elkaar heen' schrijven, ze kennen de andere server niet en verwachten niet dat er iets aan die disk veranderd buiten het eigen systeem om.

Overigens is Lustre wel recent (jaar geleden) door Sun overgekocht, en zijn ze bezig om een cluster aware fs op te zetten op basis van lustre en zfs, maar dat is afaik nog niet gereleased, en als het al gereleased is moet ik nog maar zien in hoeverre dat fatsoenlijk en stabiel gaat werken.

[Reactie gewijzigd door Kees op 30 oktober 2008 13:26]

Gelukkig export ZFS ook zeer gemakkelijk over NFS en iSCSI, en behoudt het dezelfde features aan de opslag kant. Maar goed, je gaat op een iSCSI bak GFS draaien, gezien je vragen op de OpenISCSI lijst maak je dus gebruik van die bak als iSCSI target en dat is nu net wat ZFS als gratis software oplossing voor je regelt, zonder de limitaties van Dell (op volumes enzo). Was ook direct mijn reden om geen Dell te kopen, en m'n advies aan iedereen om eens te kijken naar de limieten van NetApp op datzelfde aspect.

Wat ZFS momenteel nog mist is iscsi failover en deduplication. Het is allemaal wel mooi dat je blockdevices direct wil gebruiken om in read-write mode mee te praten, echter gezien m'n laatste benchmarks van iSCSI en NFS integratie op zowel een NetApp, Equallogic en homebuild ZFS doos ontloopt de performance tussen de twee protocollen elkaar niet. Het enige voordeel van iSCSI is bijvoorbeeld in Xen de mogelijkheid om scsi commando's direct te paravirtualiseren.

...voor een webserver heb je geheugen en een blockcache, GFS lijkt me zwaar overkill.

Wij draaien GFS op een RHEL5 cluster en daar hebben we eigenlijk nooit geen problemen mee. Het is wel eens waar een 2 node cluster waar Oracle op draait, maar de Oracle DB wordt toch flink gebruikt. Tevens hebben we een tweede cluster met dezelfde setup die een Java applicatie draait, maar daar zijn ook nooit geen problemen mee geweest icm GFS.

Misschien toch een idee om naar Red Hat te kijken ipv Debian? Je hebt immers dan gewoon support van Red Hat en zit je zelf niet avond na avond te etteren met dit soort problemen. Laat een Red Hat consultant komen om je cluster te bouwen, krijg je er een stempeltje op en Red Hat support je omgeving.

Ik was een paar jaar geleden een beetje huiverig voor Red Hat en het hele commercieele business model dat hun hebben, maar het is toch wel handig dat je een bedrijf hebt om op terug te vallen. Ik heb toch ook een aantal zaken laten uitzoeken en dat doen ze opzich best goed.

Nou snap ik best dat daar een kostenplaatje aan hangt, maar goed, jullie zijn immers groot genoeg geworden om dergelijke kosten te rechtvaardigen naar mijn mening. Maar ik heb uiteraard geen kijk in de financien van T.net of van VNU

GFS heb ik nogal wat aversie tegen. Ten eerste de development. Het klinkt allemaal heel leuk en aardig, maar als je geen (vaak verouderde) RHEL versie draait die intensief getest is, dan heb je grote kans dat het gewoon niet werkt.

Zo had ik op een gegeven moment een leuk probleem, zodra een file groter werd dan 4kb werd hij 0 bytes. Dat bleek uiteindelijk te liggen aan de versie van de kernel die ik gebruikte, ze hadden domweg een volledig brakke versie gecommit, en 'het werkte op [insert jaar oude kernel] op redhat'. Naja, maar niet op een normaal systeem.

Vervolgens moet je eigenlijk wel redhat draaien om fatsoenlijk GFS te kunnen gebruiken, want naast GFS heb je een volledige clustersuite nodig om het geheel te kunnen gebruiken, en daarnaast (wat ook voor ocfs2 opgaat overigens) heb je geen single point of failure meer.... Maar een #nodes point of failure. Als 1 node stuk gaat, ligt je cluster plat, en zelf een minuut downtime vind ik teveel (moet je nagaan hoe ik me nu voel ).

Anyway, dan kom je terug op redhat. Ja, je hebt wel support, en het kan ook vast wel lekker werken, maar het blijft redhat en rpm's, en dat is nu niet mijn meest favoriete linux distro. Er is een stuk grotere kans dat we op (open)solaris overstappen dan op redhat.

Overigens; als je Oracle gebruikt, waarom niet overstappen op Oracle Cluster File System (ocfs2)? zit waarschijnlijk meteen bij je Oracle support in .

Waar we vandaag ook achter gekomen zijn is dat het waarschijnlijk niet eens de schuld is van ocfs2. Er vielen ons een paar dingen op. Ten eerste begon het een paar maand geleden met ~1 keer per maand dat het plat lag, toen was het beter merkbaar dan nu (het ligt er nu ook uit, maar de site is grotendeels bereikbaar). Wat we in de logs zagen was dat ocfs2 over de zeik ging, en de servers ging fencen (rebooten). Daarna deden ze gewoon weer leuk mee. Het is alleen de laatste tijd, zoals je opgevallen is, steeds erger geworden.

Op een gegeven moment viel ons iets op, namelijk dat 1 server die binnen 10 seconden gereboot is, de iscsi disks niet tijdens de boot kon vinden. In eerste instantie niet heel erg op gelet, en afgeschreven op een netwerkfoutje oid. Vandaag heb ik eens een keer direct na het rebooten ingelogt, en geprobeert de iscsi machine te vinden, dat lukte niet, dus de verdenking schoof richting de iscsi machine (die sinds vanmiddag ook met een dode disk rondjes staat te draaien, wat het probleem nog erger maakt). Snel met de Dell support gebeld, doorverbonden naar ierland, en het probleem uitgelegt. De engineer snapte niet waar het probleem vandaan kwam, maar had wel een methodische oplossing; eerst de schijf vervangen, dan de firmware flashen en kijken of dat helpt.

Een paar minuten later belde hij al weer terug, volgens zijn collega's was het een bekend probleem met de firmware die wij hadden dat onder een aantal race conditions de servers de verbinding konden verliezen (waarop ocfs2 het dus handig vond om te rebooten, waardoor we die errors eigenlijk nooit zagen, tenzij iemand net op de console ingelogt was, dan had je 2s om het te bekijken).

Anyway, helaas moeten we, om de firmware te mogen upgraden, eerst de failed disk vervangen.. Ik probeer nu eerst wat andere dingen om ervoor te zorgen dat wij mischien alsjeblieft een nieuwe firmware mogen instaleren, maar tot nu toe wint de management utility het.

TLDR versie; het is de md3000i die het probleem is, ocfs2 is een gevolg die de webservers laat rebooten.

Een interessant stuk, bedankt voor je toelichting. Ik kan mij opzich wel vinden in je verhaal hoor. Ik mag dan wel eens waar RHCE-er zijn, maar ik vind RPMs niet echt super. In de tijd dat we voor een Red Hat platform kozen was het dat of Windows. Die keuze was, als Linux-mannen, dan snel gemaakt. Ik had in het begin hetzelfde insteek als jij nu hebt, hoewel ik wel stukken beter met Red Hat om kan gaan (dat mag ook wel als RHCE-er )

Maar ik ben het gedeeltelijk je eens dat je niet aan een distro moet beginnen als het je al tegenstaat om het te beheren. Of die reden vooroordelen zijn of niet laat ik in het midden, maar mijn ervaring kent dat je jezelf wel open moet stellen voor veranderen. Ik was een aantal jaar geleden immers aardig tegen Red Hat vanwege RPMs, maar opzich heb ik er nu niet zo heel veel problemen mee.

En over OCFS2, het was in de tijd de keuze van de system integrator om GFS op een Red Hat Cluster te gebruiken. In die tijd hadden wij te weinig kennis om goed te kunnen oordelen, en we zijn maar met z'n 2en. We wouden eerst Oracle RAC maar dat was te duur. Aangezien we nou al anderhalf jaar productie draaien zonder problem op dat gebied is er voor ons geen reden om over te stappen naar OCFS2.

Het iSCSI punt met de firmware lijkt aannemelijk, ik ben benieuwd. Hou ons op de hoogte en success!

Onze ervaring is dat wij meestal tegen problemen aanlopen die dusdanig uniek zijn, dat het niet (meer) boeit of er nu wel of niet een betaalde support achter zit. Ook zitten we niet te wachten op certificering, het boeit mij weinig of iets kan of 'mag' van een leverancier, als het maar goed voor ons werk. Als laatste, we hebben tijdens ons onderzoek naar distributed filesystems ook GFS bekeken, maar afgeschoten. Waarom precies weet ik niet meer, maar dat kan kees je vast wel vertellen
Oh, en als laatste punt: een grote, diep uit het hart komende aversie tegen rpm's, het is pas een beetje redelijk geworden toen ze dingen zijn gaan jatten uit de toffe systemen als apt-get, en guess who made that Ik denk dat we dus voorlopig niet van onze keuze van debian afstappen voor onze primaire systemen

Dat hebben ze ook alleen werkte de SMS server blijkbaar niet. Daardoor heeft de downtime zo lang geduurd. Aldus http://twitter.com/tweakers

mjah, die tekst die daar staat (ik gok dat je op http://twitter.com/tweakers/status/4962502438 doelt) slaat imo nergens op. de sms-server aka de monitoring bak doet het prima, alleen maakt die ook gebruik van ocfs2, dus die was ff te druk met wat anders bezig aka z'n disks.

Waarom gebruik je niet een externe monitor service puur als backup voor dit soort issues? Bijvoorbeeld Pingdom

Hé bedankt voor de tip, die is wel een stuk goedkoper dan hyperspin