Nieuwe centrale opslag - development-iteratie #104

Iteratie #104 is afgerond en in deze iteratie zit een klein aantal verbeteringen waaronder jullie eigen Community Pick! Daarnaast hebben we de nieuwe centrale opslag in gebruik genomen.

Community Pick: Mention-tag mogelijk maken in reacties onder artikelen

Zoals beloofd is de feature waarop jullie het meest gestemd hebben, ontwikkeld door onze developers. En vanaf nu kun je je medetweaker ook in de reacties bij artikelen noemen. Hiervan krijgt de tweaker in kwestie een notificatie zodat hij weet dat je hem noemde. Overigens sturen we daarbij geen dubbele notificaties als het sowieso al een reactie op de reactie was. Dit om te voorkomen dat je je door een waslijst aan notificaties moet worstelen.

Vergeten jullie niet om in Mooie Features je favoriete feature een thumbs up te geven? Of misschien heb je zelf wel een briljant idee? Krijgt jouw idee genoeg duimpjes, dan is er een grote kans dat je deze terug zal zien in de volgende Community Pick!

Aangepaste karma-beloning voor V&A-advertenties

We hebben in het karmasysteem de berekening voor Vraag en Aanbod veranderd. Deze gaven een erg hoge bijdrage voor producten bij met name groot-adverteerders. Daardoor werden zij nog wel eens als karmakoning of -keizer aangemerkt. Maar het feit dat iemand een product vaak verkoopt, zegt nog niet dat hij dan ook veel concrete gebruikservaring met dat product heeft.

Vanaf nu krijgen adverteerders met veel advertenties minder karma per advertentie; hoe meer advertenties, hoe minder karma er nog per advertentie verdiend kan worden. Dit effect wordt overigens pas goed zichtbaar vanaf onze eerstvolgende herberekening in juli.

Zoekbalk boven aan elke pagina in de Pricewatch

De zoekbalk was altijd al beschikbaar vanuit de header binnen ons responsive design, maar heeft nu ook een prominente plek gekregen boven aan elke pagina binnen de Pricewatch. Zo kun je makkelijker verder struinen tussen alle producten.

Nieuwe centrale opslag: van ZFS naar Ceph

In 2015 schreven wij al over ons verlangen om de oude Solaris ZFS-omgeving te vervangen door iets wat aan al onze wensen voldeed. Zowel de reacties onder dat artikel als wijzelf kwamen tot de conclusie dat een Ceph-cluster de geschiktste oplossing zou zijn voor onze eisen. Onder die eisen vielen het automatisch opslaan op meerdere locaties van bestanden, het voorkomen van downtime als er een server uitvalt en de aanwezigheid van een Posix-filesysteem, zodat we zonder al te veel moeite over konden stappen. Daarnaast bestaat een Ceph-cluster veelal uit goedkope hardware, waardoor wij voor een volledige ssd-opzet konden gaan.

In de afgelopen maanden hebben we samen met 42on dit Ceph-cluster ontworpen en opgezet. In de afgelopen maanden hebben we dit nieuwe cluster langzaam in gebruik genomen. Dit cluster draait Ceph Kraken en bestaat uit drie Monitor-servers, twee Metadata-servers en zes servers die in de opslag voorzien. Dit cluster biedt vervolgens zijn files aan via cephfs en onze virtuele servers draaien nu allemaal met rbd.

Taak	Cpu	Mem	Opslag
3x Monitor	E3-1240 v5 @ 3,50GHz	16GB	2x Intel S3500 120GB-ssd
6x Opslag	E5-2640 v4 @ 2,40GHz	32GB	6x Intel S3510 1,6TB-ssd
2x Metadata	E3-1271 v3 @ 3,60GHz	32GB	250GB sata

Dankzij dit cluster hebben wij nu zo'n 57TB bruto beschikbaar om onze files op te slaan. Dat lijkt veel, maar netto blijft hier ongeveer 16TB van over omdat alle files op drie verschillende servers opgeslagen worden en je de disks niet voller dan tachtig procent wil hebben. Mocht dit niet genoeg blijken in de toekomst: alle opslagservers hebben nog plaats voor vier extra disks, waardoor wij de opslag relatief eenvoudig kunnen uitbreiden.

Bugfixes

• Grafieken in tabs werden niet goed of helemaal niet getoond (o.a. in Firefox).
• Een aantal re-directs voor oude url's van de aboshop gaven errors.
• Bij een aantal notificaties werden dubbele e-mails verstuurd.

Reacties (90)

11 bakken voor 16TB data? Is Ceph niet alleen handig als je richting petabytes gaat schalen, maar voor een dusdanig kleine setup is de overhead toch enorm... Wat was de gedachte hierachter?

Omdat wij een storage systeem wilden hebben dat 'gewoon' ontworpen is als highly available en eenvoudig over meerdere locaties gesplitst kan worden en geen handmatige failover nodig heeft op het moment dat er een server uitvalt.

Het probleem is dat met onze relatief kleine dataset en budget je daar eigenlijk geen fatsoenlijke 'vendor' oplossing voor kan vinden. Let wel, dit hele cluster kost nog steeds een stuk minder dan de offertes van 'de grote jongens' waarbij je dan nog niet eens een high-available-multi-site setup hebt.

Ja, het is overkil, we hadden een aantal rollen kunnen combineren maar dat werd afgeraden. Op deze manier kan een rebuild van je cluster niet de monitors onderuit halen en een crashende MDS server heeft geen invloed op je storage. We hadden de ruimte en budget ervoor dus het was geen probleem om dat te splitsen.

eenvoudig over meerdere locaties gesplitst kan worden en geen handmatige failover nodig heeft op het moment dat er een server uitvalt.

Staan de server nu dan ook op meerdere locaties of is dat voor de toekomst.

Die staan nu al over 2 locaties verdeeld (wel beide in amsterdam) om problemen met een hoster te voorkomen (zoals ddos aanval op 1 provider (niet perse op ons), stroom problemen, route problemen, overstroming, brand in een locatie etc).

Want een overstroming treft maar één locatie in Amsterdam? Ik denk het niet. Zelfde als route of stroom problemen. Een andere locatie noem je oost/zuid Nederland en niet in één stad.

Met route(r) problemen bedoel ik dat een hoster problemen heeft met zijn verbindingen en/of router. Het komt niet vaak voor, maar ook de corerouters van een grote hostingbedrijf kunnen onderuit gaan. Als je dan 2 hosters hebt blijft de tweede in het algemeen wel gewoon up.

Qua stroomproblemen hebben beide locaties hun eigen voorzieningen. Mocht er een volledige amsterdamse stroomstoring optreden dan moeten ook op beide locaties de noodvoorzieningen uitvallen voordat we er last van hebben.

En mocht een overstroming zo groot zijn dat heel amsterdam onder water staat dan hebben we - naast natte voeten - een probleem inderdaad.

Hebben jullie ook overwogen om bijvoorbeeld AWS S3 in te zetten? En dan CloudFront of CloudFlare als CDN.
Was dat duurder? Of kon het niet met de wensen?

[Reactie gewijzigd door djwice op 18 april 2017 23:02]

Even kijken; 15TB opslaan in 2 availabilty regio's UK en DE:
UK: 15×1024×0.024 =~ 370$
DE: 15x1024x0.0245 =~ 375$
Cloudflare laat geen prijzen zien voor het enterprise product dat wij zeker zouden afnemen, dus laten we dat zetten op 2x het duurste pakket: $400. Verder betaal je per 10,000 requests $0.0043 dat komt in ons geval op zo'n 275$ per maand uit (met zo'n 650 miljoen requests per maand)

Dan kom je dus uit op een kleine 1400$ per maand en over 5 jaar bekeken betaal je dan ongeveer 2x meer dan dat wij nu hebben neergelegt.

AWS prijzen voor opslag dalen zo'n 20% per jaar.
Waarom wil in DE en UK opslaan? Elk bestaat opzich al uit 2 of 3 fysiek gescheiden data centra. En waarom niet Ierland?

[Reactie gewijzigd door djwice op 19 april 2017 13:57]

Omdat je niet in 1 availability zone wil zitten. Als die onderuit gaat (zoals laatst gebeurde in de US) dan wil je nog wel bij je data kunnen komen.

Dat zoals in de US was de eerste keer in 15 jaar en zal niet meer gebeuren.

Heb je nu de data van Tweakers ook over meerdere landen verdeeld? En elk met 3 data centra? Klinkt beetje overkill als je het mij vraagt.

Bovendien heb je dat risico al met je CDN ondervangen (CloudFlare); caching van je S3.

Ik was hier zelf ook verbaasd over en zou graag meer horen van Tweakers. Ik begrijp dat performance een keuze is, ik begrijp dat je futureproof wilt zijn, maar deze setup schreeuwt "inefficientie". Wat storage betreft heb ik dan ook wel weer bij te leren, dus een wat uitgebreidere motivatie zou ik zeker waarderen.

Dit is een HA storage cluster. Met 1 monitor zou het geen cluster meer zijn (monitor uit, cluster weg). Met 2 monitors is het ook nog niet veilig (1 monitor uit, 2de weet niet zeker of dat zo is, dus cluster weg). Met 3 monitors kan er altijd 1 uitvallen (dan kunnen de andere 2 hem uit het cluster schoppen want ze hebben een meerderheid). Dus 3 monitors.

Deze monitors zou je kunnen combineren op de storage servers, maar op het moment dat er dan iets misgaat in het cluster en zowel de storage als de monitors ineens heel veel werk moeten doen, dan heb je kans dat de verschillende taken elkaar gaan verdringen en bijvoorbeeld de monitor een heartbeat mist en daardoor uitvalt. Als dat dan ook met 1 van de andere twee gebeurd is het einde verhaal voor het cluster. Dus wil je die taken fysiek scheiden zodat ze elkaar niet in de weg gaan zitten.

Vervolgens wil je je data veilig opslaan. Dat kan met een 'raid-1', dus alles 2 keer opslaan, maar omdat dit op 'goedkope' hardware draait en het risico op uitval van individuele componenten hoger ligt dan bij een dure storageoplossing slaan wij alles 3 keer op. En op deze manier ligt tweakers.net er niet uit op het moment dat er iets mis gaat met de storageomgeving.

Als ik het goed lees dus je hebt 3 monitors waar er 2 van online moeten zijn. dus als er 1 uitvalt moet je er snel bij zijn voor er een 2e uitvalt. (snel erbij zijn kan dus ook betekenen dat je een storage server herconfigureert als standby monitor?)

Klopt, al zou ik dan waarschijnlijk een andere server dan de storage servers als monitor inzetten (bijvoorbeeld een webserver, daar heb ik er genoeg van). Maar dat doe ik alleen als die andere server echt niet meer gaat terugkomen. Een reboot oid zal meestal geen problemen opleveren.

Ze kunnen in essentie zelfs alle 3 online zijn, maar je netwerk kan een probleem hebben. Daarom wil je een minimum van 3 monitors die uiteindelijk in staat zijn om met een meerderheid te beslissen (je zal dus steeds een oneven aantal nodig hebben). Verdwijnt er 1 uit het netwerk dan weet die ene monitor dat deze geïsoleerd staat omdat deze het contact met de 2 andere is verloren en zal op dat moment geen enkele actie meer ondernemen.

Hoe is dit geregeld met de twee locaties? Staan deze servers verdeeld over de twee locaties of heb je op de tweede locatie een ander opslagsysteem draaien?

Deze servers staan verdeeld over de 2 locaties (4 opslag op de 1, 2 opslag op de andere locatie). Als de hoofdlocatie eruit valt hebben wij wel een 'probleem'. Het cluster zal dan niet meer werken. Maar alle data is er nog wel en we zouden door een aantal aanpassingen het cluster weer kunnen gaan gebruiken als blijkt dat de hoofdlocatie definitief verloren is.

Tussen de twee locaties ligt een redundante 10GBit/s verbinding waardoor de latency vrij laag is en dit mogelijk is.

Met Ceph heb je altijd 3 monitors nodig. Je kan kiezen om dit op de storage servers zelf te draaien, maar je kan er uiteraard ook voor kiezen om dit apart te draaien. Hier is dan ook voor gekozen blijkbaar.

Daarnaast kan je de storage servers gewoon in de breedte uitbreiden. De monitor en metadata servers hoeven daarvoor niet uitgebreid te worden. Er zijn ook nog 6x4 slots vrij voor disks, dus dit kan nog uitgebreid worden in de toekomst.

Gezien in 2015 (in het gelinkte artikel) men ervanuit ging dat ze onder de 30TB zouden blijven, en dan nu er ruim voldoende is met 16TB kun je aannemen dat je datagroei niet zo hard gaat. Bijschalen is leuk, maar tegen de tijd dat je de 100TB gaat bereiken is de technische levensduur van deze setup allang verstreken.

Oftewel: is het een IT speeltje en als setup een beetje over-the-top voor de toepassing of verwachten jullie expotentieel meer data op te slaan de komende maanden?

Storagesystemen draaien niet uitsluitend om het opslaan van vele TBs, in het geval van T.net is high available in combinatie met multi site belangrijker. Mochten ze bijvoorbeeld in de toekomst op 4K video gaan opslaan dan is Ceph flexibel genoeg om te voorzien in deze data behoefte.

Het interessante van Ceph is dat als de hardware over bijvoorbeeld 5 jaar niet meer voldoet, je nieuwe hardware aanschaft en de oude hardware uitwisselt zonder dat het Ceph cluster down gaat. In theorie draait over 25 jaar T.net nog steeds op het zelfde Ceph cluster.

[Reactie gewijzigd door squaddie op 18 april 2017 19:03]

waarom draait tweakers niet bij amazon, de grootste cloud provider? Daar heb je diverse services beschikbaar zonder om te hoeven kijken naar details of fysieke aanschaf va hardware. s3, dynamodb, rdb etc zijn prima tools voor sql,nosql en redundant storage.

- Kosten (AWS zou ons -ballpark figure, maar vrij realistisch- ongeveer 2x-3x meer kosten per jaar dan dat we nu aan servers uitgeven; qua mankracht winnen we er ook niets mee).
- Snelheid/specificaties (onze servers zijn bloedsnel, maar ook specifiek samengesteld voor die performance, dus soms weinig snelle cores met veel geheugen; iets wat bij amazon niet kan).
- Betrouwbaarheid (AWS ligt er vaker uit dan onze hosting)
- Locatie (geen datacentrum in .nl, dus hogere latency voor gebruikers)
- Onze architectuur bestaat niet uit microservices, herschrijven kost domweg teveel tijd en geld, zeker als we daarna meer moeten uitgeven aan hosting dan dat we nu doen - dat kan ik niet verkopen intern.

Heel goed Kees! Het wordt eens tijd dat mensen gaan inzien dat de cloud niet altijd de Holy Grail is

Hear hear. Azure en AWS hebben dusdanig veel downtime dat je betrouwbaarder af bent door zelf te hosten. Een plaatselijk datacenter is dan nog vaak wel iets handiger qua hardware, backups, veiligheidseisen, infrastructuur et cetera maar die internationale providers maken er een puinzooi van.

Azure en AWS hebben dusdanig veel downtime dat je betrouwbaarder af bent door zelf te hosten.

Dat valt wel mee, zeker als je de cloud gebruikt zoals het moet en dus niet een enkele instance maar meerder verspreid over de wereld. Dat vereist ook wat van je applicatie.

Mensen die dat niet inzien noem je verkopers

Ik neem aan dat iedere respectabele manager of IT-er wel eerst een kostenoverzicht of PoC maakt voor ze in het 'diepe' springen....

Heb ik gedaan, ik ga van rond de €40.000 per maand naar nog geen €700,- per maand en van 2 data centra naar 3 en met nog eens 2 caching locaties in NL.

En mijn hele boeltje is in een paar uur van Ierland naar Frankfurt verplaatst, mocht dat nodig zijn.

Let wel, om dit te bereiken moet je zeer selectief zijn in je keuzes.

[Reactie gewijzigd door djwice op 18 april 2017 23:16]

OK, kun je dat eens toelichten? Je gaat nu van hosting in een eigen (gekozen) datacenter van EUR 40.000 per maand naar de Azure of AWS voor nog geen EUR 700 per maand? Of begrijp ik het verkeerd?
En hoe is dat mogelijk...??

We haddeb IBM meuk met licenties met alles statefull, full blown shebang. ESB, Java Portal, CMS met PHP, meerdere lagen Firewalls, Routers, Loadballancers etc. voor 2500 pagina's content, 100 formuliertjes en een mijn omgeving voor ~ 2.2 miljoen klanten.

We gaan over op serverless met NodeJS, stateless, met Angular2 front end. Waarbij grote delen al pre-renderd uit build komt.

Dus van overkill en zwaar geschut naar; hoe doen we dit zo kosteneffectief mogelijk met zo veel diversiteit als nodig. Met allen open source en cloud native componenten.

Aantal randvoorwaarden gecreerd zoals DRY, BDD en interne NPM. Dievhelpen om dingen 1x te doen en daarna her te gebruiken. Dan wel hergebruiken en voor iedereen verbeteren. En dus ook minder complexitreit en dus simpel te hosten.

[Reactie gewijzigd door djwice op 19 april 2017 14:19]

De cloud kan zeker nut hebben, maar het is niet altijd de oplossing. Als we nu met een nieuwe site zouden beginnen dan zou dat zeker in de cloud gebeuren.

S3 heeft er in 15 jaar 4 uur uitgelegen.
Jullie minder?

AWS heeft twee EDGE locaties in Amsterdam. Je kunt daar naast je CDN (CloudFront) ook Lambda@Edge draaien voor logica zoals input filtering, A/B testen, routing, FireWalling, wel/geen cookie wall, etc.

200 miljoen REST API calls die elk 200ms duren kosten op AWS nog geen €100,-.

En door CloudFormation is mijn teststraat exact gelijk aan productie (op een paar firewall settings en persoonsdata na).

[Reactie gewijzigd door djwice op 18 april 2017 23:21]

200ms voor een API call is wel vrij hoog, is het standaard dat het zo langzaam is?

Ik heb even gekeken naar onze huidige interne api calls. Daarvan doen we er zo'n 200 miljoen per week en die zijn gemiddeld in minder dan 2ms klaar. Bij amazon zou dat dus zo'n 400€ kosten per maand dus zou ik een budget van 24k€ kunnen reserveren voor servers die 5 jaar meegaan.

De cloud heeft zeker ook voordelen, vooral als je met een nieuwe applicatie begint. Een bestaande applicatie zul je eerst moeten omschrijven en met een applicatie die zo complex is als die van ons met heel veel onderdelen en oude code dan ben je al snel jaren daarmee bezig.

Nee, 200ms was mijn overschatting van de CPU tijd die je API zou gebruiken om een overschatting van de kosten te krijgen (die dan m.i. nog pinda's is). AWS rekend API calls in CPU tijd af.

Bij ons zien we bijvoorbeeld 1.800 ruliere expressie tests in een API binnen enkele ms afgehandeld worden.

Incl. het loggen van elk resultaat.

[Reactie gewijzigd door djwice op 19 april 2017 14:30]

Nu heeft ZFS veel van object storage en zou ik toch eens graag de voor en nadelen horen van een onpartijdige bron.
Waarom kozen jullie bvb voor Ceph en niet voor OpenIO bv en welke erasure encoding gebruiken jullie (10,4)? of enkel replicatie?

We gebruiken enkel replicatie, geen erasurecoding. En de keuze voor ceph is omdat het al even stable is en, in tegenstelling tot openio, zich al zeker bewezen heeft in veel productieomgevingen.

ZFS is een filesysteem, dat is compleet iets anders dan een cluster als ceph. ZFS draai je op 1 machine, als die machine plat gaat heb je geen filesysteem meer. Dan moet je al naar andere oplossingen kijken zoals shared disks en kom je al heel erg snel uit op een oplossing die een veelvoud kost van wat wij nu hebben staan.

Je kunt ook nog steeds ZFS onder Ceph blijven gebruiken.

Zie bijvoorbeeld: http://kernelpanik.net/running-ceph-on-zfs/

Ben benieuwd hoe jullie setup er compleet uit ziet van de Ceph storage en waarom er bijvoorbeeld gekozen is om de monitoring en metadata apart op een server te zetten (logische wijze om performance maar kost ook meer).

+1

Maar als "ijzerliefhebber" ben ik ook benieuwd naar zaken als:
Welk Chassis
Welke HBA's (en waarom)
Wel of geen (SAS Expander, Non expander) backplane (en waarom

Chassis zijn (voor de storageservers) 'gewoon' de R420 van Dell met ruimte voor 10x 2,5" schijven, een 10-core CPU, wat geheugen en een (dual) 10GBit/s SFP+ kaart. Verder geen spannende HBA's of enclosures.

De reden daarvoor is dat je niet 1 server teveel werk wil laten doen en we niet zoveel opslag nodig hebben (in ceph-cluster termen is ons cluster eigenlijk gewoon een minicluster). We hadden ook 4 servers kunnen opzetten die alle data aan boord hadden, maar als er dan 1 uitvalt heb je een probleem en moet je een kwart van je data herschrijven.

de R420 hebben ruimte voor 8x 2,5" toch ?

@xleeuwx De R420 heeft ook een model met ruimte voor maximaal 10x2,5"
Zie ook http://www.dell.com/nl/bedrijven/p/poweredge-r430/pd en dan het kopje "Drive bays"

Zoals @Kees hieronder zegt is het de 430 niet de 420

Verklaard ook wel een hoop meer want de 420 is al een tijd uit (2012) en de 430 is nieuwer (2014) en dus logischer om aan te schaffen.

Excuus, ik bedoel de R430

bedankt voor de aanvullende info @Kees

juist hier had ik het "verschil" verwacht
zoals de HBA's en backplane keuzes, onboard sas controllers hebben vaak niet de throughput (erg lage clockcycle processor)

aangezien juist CEPH de "RAID" functie voor zijn rekening neemt leek me een zo dom mogelijke,en zo snel mogelijke SAS HBA een belangrijke keuze.

wel of geen SAS expander backplane tja daar zijn verschillende meningen over, ik weet niet wat de default is voor een R430 (had zelf voor een non expander gekozen om het OS full controll te geven)

ik werk momenteel aan de (ff makkelijk gezegt) microsoft variant (S2D) waar dit juiste de bepalende factoren zijn voor performance (buiten disk keuzes)
vandaar dat ik juist hier benieuwd was naar jullie specificaties / visie

Dit inderdaad, er zijn al best wat bedrijven die Ceph FS draaien maar hoor ook heel veel performance issues op dit gebied met backups enz enz.

Oef, voor een 16TB systeem vind ik het wel heel erg prijzig. 1000 euro per SSD, 36.000eur dus voor 16TB... Waarom hebben jullie niet voor goedkopere disks gekozen ?

De write amplification van Ceph maakt dat je erg snel door goedkopere SSD's heenbrandt als je veel schrijft. Er had wel voor erasure coding kunnen worden gekozen om meer netto opslag te krijgen, maarja dan moet je er toch weer een mirror cache tier boven plaatsen en dat is weer extra beheerslast. Een opstelling zoals hier beschreven is voor Ceph niet ongewoon, maar 11 fysieke servers draaiend houden om 16TB data op te slaan blijft natuurlijk een apart concept

[Reactie gewijzigd door Bigs op 18 april 2017 12:56]

Omdat je dan ronddraaiende harde schijven hebt die veel trager zijn dan de SSD's. Mischien merk je het niet in het dagelijks gebruik maar op het moment van heftige lees/schrijfacties (backups, crashes, repairs, scrubs) merk je het wel erg goed. Overigens hebben wij geen 1k euro per ssd voor betaald, dat lag lager..

@basdej de 1000€ is natuurlijk niet wat je betaald als meerprijs maar meer wanneer je ze per stuk koopt. Zeker in deze aantallen zit er vast een leuke korting op

Begrijp ik uit het verhaal nu goed dat de storage op de servers verder niet in een raid set of iets dergelijks staan? Want als ik de hoeveelheid storage per server x het aantal servers doe dan kom je op die 57TB uit en bij raid zou je toch een verlies hebben.

Met Ceph is RAID niet aan te raden. Hoe meer verschillende disken, hoe beter je data verspreid is. Ceph regelt dan vervolgens de replicatie van alle data over 3 verschillende servers & disken, afhankelijk van je setup.

Als er een disk uitvalt, is er hierdoor altijd een andere kopie op een andere schijf verdeelt.

Wat ik mij in het geval van Tweakers wel afvraag, is of ze alle schijven van hetzelfde merk en type hebben? Volgens mij wel. Dit wordt juist niet aangeraden. Stel dat er een productiefout in de schijven zit, heb je sneller de kans dat dat over je gehele storage platform gebeurd. In een Ceph cluster die ik aan het opzetten ben heb ik daarom ook 6 sandisks en 6 intel disks. (3 servers met 4 schijven p.s.)

Deze schijven komen allemaal bij Dell vandaan en het zijn allemaal Intel S3510's. Als ze allemaal gelijktijdig uitvallen hebben we inderdaad een probleem maar de kans daarop (en de kans dat ze binnen een paar dagen falen) lijkt mij niet overdreven groot *afklopt*.

Ik neem aan dat jullie op deze servers iets van dell pro support Next businessday onsite hebben genomen of 4 uur mission critical?

Ik kan bevestigen dat de pro support van Dell erg goed is. Voor onze oude centrale storage hadden we een Dell EqualLogic. In 6 jaar tijd maar 5 defecte HDD's gehad. Wanneer dit midden in de nacht gebeurde werd ik netjes door Dell wakker gebeld met de vraag hoe laat de vervangende HDD per koerier afgeleverd kon worden en of ik daar wel of niet een engineer bij zou willen. De HDD is was dan nog geheel defect maar er werd een slechtere performance door unit geconstateerd waarop dus tijdig werd gehandeld.

5 jaar NBD support zit er inderdaad op. De 4h mission critical is enigszins overdreven voor een cluster welke 3-dubbel is uitgevoert. Een disk kan dan makkelijk een dag later pas vervangen worden.

Er zit op deze servers (itt die van IBM/lenovo) helaas geen call-home functionaliteit, dus dell zou mij niet wakker bellen. Maar mijn eigen monitoring is goed genoeg dat ik dan zelf de dag erna bel en de dag daarna de disk kan vervangen

@Kees dit zou je wel moeten kunnen inregelen op basis van de ingebouwde iDRAC en de Dell SupportAssistant. Zie ook pagina 7 van http://en.community.dell...._papers/20441294/download

Dus het is niet out-of-the-box direct actief maar het zou wel redelijk eenvoudig te realiseren moeten zijn

Thanks We zijn pas recent weer naar Dell overgestapt, dus ik heb nog wat bij te leren.

Als je het op deze manier ingeregeld hebt hoef je dus niet meer zelf met support te gaan bellen en zij beschikken direct over de benodigde gegevens. In jullie geval zal de vervangende SSD dus maximaal een dag later bezorgd worden. Wij "misbruiken" onze storage beheer server voor het doen van de meldingen naar Dell voor zowel de vSphere servers als voor de Dell SAS compellent en het bijbehorende enclosure. Het grote voordeel van deze inrichting is dat je dus maar 1 server toegang hoeft te geven in de firewall en je jouw storage omgeving geen directe toegang tot het publieke internet hoeft te geven.

Via de Dell lifecycle controller van deze servers kun je makkelijk updates doorvoeren. Zowel wat drivers betreft als voor firmware en het BIOS. Dit kun je centraal allemaal inregelen. Gezien het beperkte aantal servers die wij hebben staan staat dit bij iedere server gewoon op zich. Je dient dan gewoon te zorgen dat de server toegang tot het internet heeft en bij het opstarten van de server geef je aan dat je wil booten naar de dell lifecycle controller. Vanuit daar kun je dan aangeven dat je direct vanaf de online servers van dell wil updaten. Eventueel een private FTP behoord in deze setting ook tot de mogelijkheden .

In een duister verleden heb ik wel eens gehad dat we 60% van de schijven moesten vervangen in de eerste maand. Iets met de naam Maxtor. Maar dat is ook het enige moment dat ik het heb meegemaakt, of mee heb gekregen.

Dit is wel echt een flinke tijd terug, maar al die nachtelijke uren in het datacenter blijven je wel bij eigenlijk.

Dat is wel vervelend inderdaad. Ik heb ooit 1 server gehad die elke schijf die we in een specifiek slot staken binnen een week dood kon krijgen en dan ook echt stuk. Daar hebben zijn we in 3 weken tijd 3 disks aan 'kwijt' geraakt totdat er een stuk ducttape over dat slot ging

Dus het is een beetje te vergelijken met een virtual SAN van VMware? De website van Ceph is niet echt heel duidelijk met zijn uitleg van hoe het in elkaar zit.

Die metadata servers zijn dan voor de raid achtige functionaliteit?

Als ik zo de spec van tweakers lees is er best veel hardware nodig om de opslag te realiseren. Ik vraag met toch af of een SAS-compellent zoals wij die hier hebben staan dan niet al snel goedkoper gaat zijn.

De metadata servers doen alleen het 'cephfs' gedeelte van ceph. Dat is - heel kort gezegt - een drop-in replacement voor NFS dat wij tot nu toe gebruiken (maar dan wel veel schaalbaarder en high available).

Ik weet niet wat een virtual SAN van VMware is, maar ceph is inderdaad een 'software defined storage' omgeving waarbij ik dit cluster als virtuele SAN gebruik. In het geval van de VM's gebruik ik de 'iscsi' variant RBD voor het opslaan van de images zodat alle 3 de VM servers bij dezelfde images kunnen komen.

Virtual SAN van VMWare is dat je in de hosts local storage zet die met mekaar via de vCenter-server gedeeld en redudant wordt uitgevoerd. Dus bv. 7 hosts die allemaal met local storage uit zijn gerust en waar vSphere er 1 datastore van maakt (waar alle hosts dan mee kunnen werken).

http://www.vmware.com/con...virtual-san-datasheet.pdf

[Reactie gewijzigd door joker1977 op 19 april 2017 20:56]

Interessante upgrade. Gezien we nu over zijn op een volledig SSD-platform, is er ook prestatiewinst geboekt bij het serveren van pagina's. Ben wel benieuwd naar de overall performance winst als die er is. En ja, gewoon voor de l0lz.

In de praktijk zal dat wel meevallen voor deze aanpassing denk ik; alle 'warme' content, dus afbeeldingen van frontpage artikelen of avatars van users in actieve topics, zitten over het algemeen toch al in de cache van de webservers. Het voordeel van SSD's is vooral dat de impact niet zo groot is als die caches een keer geleegd worden, plus dat je natuurlijk sneller zaken weg kunt schrijven.

Klopt, de voornaamste winsten zie ik in de performance van mijn VM's (en daar draaien alleen dingen op die de eindgebruiker niet raken zoals Jenkins e.d.).

Verder zie ik een enorm voordeel op het moment dat er grote video's worden geupload; vroeger blokkeerde het schrijven van een 4-5G grote videofile soms alle operaties op de storage waardoor alle webservers ineens met een load van 100+ zaten en een hele rits apache proccessen in de 'D' state, of in het ergste geval zelfs tweakers helemaal onderuit trokken.

En daarnaast zijn SSD's gewoon hip en paste het in het budget

Hehe.. atijd frustrerend als storage systemen (die zonder SSD's) ineens trager zijn dan de SSD in je laptop SSD's zouden gewoon de norm moeten zijn in servers, maar helaas heeft nog niet iedereen het budget daarvoor.

Naast het budget heb je natuurlijk ook nog het doel waarvoor het wordt gebruikt. Daarom maken wij op het werk bijvoorbeeld gebruik van een SAS compellent met een extra enclosure er aan. De compellent zelf heeft SAS HDD's en SSD's. Op de SSD's zit een volume met caching en de SAS HDD's zijn vervolgens voor de opslag. In de encolusure zitten vervolgens SATA HDD's aangezien deze puur voor de backup worden gebruikt. Met alle deduplicatie enz. hebben snellere disken verder ook geen nut.

Naast dat het voor mij dus weinig nut heeft om in zo'n configuratie volledig op SSD's te gaan draaien zou het ook een flinke aanslag zijn op mijn budget. En gezien het om een onderwijsinstelling gaat betekent dat dat je ergens anders op zou moeten bezuinigen om hier meer budget voor vrij te maken. Ik begrijp dus wel waarom bedrijven voor andere oplossingen kiezen.

.mentionDiv.dropdown ul li .thumb img {
width: 100%;
height: auto;
}

Nog even deze code doorvoeren en de avatars passen weer in de typeahead-preview

Thanks, bij deze gefixed

Waarom hebben de Metadata servers geen SDD? Binnen het kostenplaatje moet dat vast nog wel gepast hebben. Zit er nu alsnog een HDD bottleneck in het systeem?

Het waren 'oude' servers die ik nog had liggen. Maar de metadataservers doen vrijwel niets met hun disks, al het werk gebeurd in het geheugen. SSD is daar overkill.

5 'overhead' bakken voor 6 storage bakken, voor een totaal aan 16TB storage ... waw. Ik ben per direct geboeid waarom Ceph ... Wanneer wordt dit als efficient gezien ?

Een achtergrond artikel van Ceph mag wel eens langskomen

Wat is efficiënt? Je kunt het eigenlijk niet vergelijken met een RAID 1 pizzadoos met ZFS.

Je bent met een dergelijke ceph-opstelling inderdaad meer diskspace kwijt (alles 3x in plaats van 2x) maar je krijgt er wel een high available cluster voor terug dat ook lekker schaalbaar is naar hoeveelheden storage die je sowieso niet in een simpelere oplossing kwijt gaat kunnen.

Mijn werkgever heeft nu ongeveer een half jaar twee ceph clusters in omgeving en tot nu toe absoluut geen spijt van deze keuze.