21/09/16 09:15
Monitor en OSD kunnen gecombineerd worden.
Monitors schrijven. Dat is niet echt intensief. Dat doen ze naar de OS disk overigens.
Metadata is voor CephFS. Dat gebruik je nu niet.,
Dus met 3 servers met daarin 2 SSD OS disken en dan minstens 1 storage disk per server heb je alles wat je nodig hebt.
Je hebt daarnaast niets anders nodig.
Laatst gewijzigd door Tuxis_IE; 21/09/16 om 09:18.
21/09/16 09:27
Wij draaien een productie cluster ceph op een server met SD kaart (voor boot en ceph logs). Onze configuratie is per server 2x SSD en 10x SATA 7200rpm. Door SSD als cache te gebruiken zie je op de SATA disken véél minder IO en behaal je toch belachelijke performance. Ik zit nu te kijken op de server en zie 80MB/s write, 160MB/s read en de logs doen maar 200kb/s dus dat valt allemaal mee... geen SSD voor nodigOorspronkelijk geplaatst door sandermoors
Skynet ICT B.V. - The cause of the problem is: the printer thinks its a router.
21/09/16 09:28
Ik zou niet adviseren om één grote disk per server te doen dan is de impact bij uitval van de disk meteen vrij groot. Ik zou 2x SSD toen en minimaal 2x een SATA disk van (bijv) 1TB. Bij uitval is het maar een zesde ipv een derde van je data en dus minder kritische.
Skynet ICT B.V. - The cause of the problem is: the printer thinks its a router.
21/09/16 09:57
In het geval van drie nodes maakt het niet zo veel uit.Ik zou niet adviseren om één grote disk per server te doen dan is de impact bij uitval van de disk meteen vrij groot. Ik zou 2x SSD toen en minimaal 2x een SATA disk van (bijv) 1TB. Bij uitval is het maar een zesde ipv een derde van je data en dus minder kritische.
Uitval van een node heeft nl dezelfde inpakt als de uitval van een disk wanneer je 1 disk in een node stopt. Beide kunnen afgevangen worden door Ceph. Het is een afweging.
Als je niet zo veel terabytes nodig hebt, dan zou ik alleen SSD's doen. Want heel veel terabytes per node met weinig nodes is ook niet handig.
Wij hebben snelheden van grofweg 1 Gbyte/s (je leest het goed) gehaald. Was het wel met 10 Gbit gekoppeld. Drie nodes. SSD storage. Verder geen spannende hardware.
De "instap" clusters die we uitrollen hebben per node 2x 1 Gbit/s en er wordt begonnen met 1 a 2 storage SSD's.
Uitval van een node heeft nauwelijks impact op het cluster. Natuurlijk gaat Ceph even aan de slag maar in de praktijk merk je daar weinig van. Ceph doet dat erg goed. Het word hooguit even wat slugish, maar nooit echt traag.
Er is wel een grens natuurlijk.
Als je 10 Terbayte in drie nodes stopt en al die T's ga je druk gebruiken door het vol te duwen met VM's die allemaal flink wat IOPs doen moet je netwerk aan de achterkant wel wat sneller worden. Dat zal geleidelijk gebeuren een een mooie upgrade voor later. Je ziet het dus aankomen.
21/09/16 11:16
Het is de vraag of SSD's nodig zijn want wij halen ook 1Gbit/s met SATA disken en SSD cache. Het is sterk afhankelijk van hoe je het gebruikt en wat er precies op komt te draaien. Wij draaien er bijv Windows servers op (terminal servers) die veel IO doen, hiervoor hebben we SSD cache. De rest van de servers doet eigenlijk niet heel veel speciaals (dus waarom zou ik dan tig SSD's kopen).
Meten is weten. Advies aan de TS, maak een testopstelling en speel er mee. Daarna weet je wat je nodig hebt. Regel is: meer disken, meer snelheid en minder snelheid per disk nodig.
Skynet ICT B.V. - The cause of the problem is: the printer thinks its a router.
21/09/16 12:45
1 Gbyte/s niet 1 Gbit/s.Het is de vraag of SSD's nodig zijn want wij halen ook 1Gbit/s met SATA disken en SSD cache
En uiteraard is het afhankelijk van waarvoor je het gebruikt. Hoeveel storage je nodig hebt. Basicly de prijs per Gbyte en de gewenste snelheid.
SSD caching werkt zeker erg goed. We hebben die opstelling ook in productie draaien voor een klant. SSD cache en spinning disken en veel Terabytes storage en goede performance. Weet even niet hoe hard dat ging maar ook hard in ieder gevan :-)
Het is ook wat kort door de bocht van mij om zomaar te stellen wat ideaal is.
Mijn redenering is:
Maar wanneer je 1,2 of 3 T nodig hebt is het niet de moeite om SSD cache te gaan doen met normale disken. Zeker ook omdat de 1 Tb SSD's redelijk betaalbaar zijn en de snelheid toch wel erg lekker is. Net wat lekkerder dan met SSD cache. SSD cache is wel voordeliger ongeacht het aantal Tb's dat je nodig hebt.
Voor de oorspronkelijke vraag kun je dus uit de voeten met 3 nodes met in totaal 3 SSD's van pakweg € 450,00 het stuk voor de storage.
Anders heb je 3 SSD's nodig voor de cache (die overigens ook uit kunnen vallen) van pakweg € 80,00 en 3 disken die ook € 100,00 het stuk zijn. Maar dat is dat niet zo ideaal. Je zou dan liever 6 disken hebben zodat, wanneer iets niet uit de SSD cache komt, het toch wel crispy blijft.
Dus 1,5 Tb netto storage met SSD kost € 1350,00 aan disken
1,5 Tb met SSD cache en spinning disks kost € 540,00 aan disken (1 spinning disk van 1 Tb WD Red) Als je 2 Tb disken pakt is spinning disks per Tb natuurlijk veel goedkoper.
Neem groei mee. DIe 1 TB SSD's kosten volgend jaar nog maar de helft. Dus als je NU aan 1,5 Tb genoeg hebt..
En ja, testen, testen, testen..
22/09/16 17:16
1 = geen. Zeker als je met Ceph gaat werken is het onverstandig om te werken met, zoals ik al eerder zijn, 1 disk per server. Het is in dat geval veel logischer om 2x SSD en 2x SATA in een server te zetten. Bij uitval van 1 disk is het 1/6e van je data die kwijt is (niet 1/3e, wat veel meer tijd kost om weer te levelen). Dit staat los van of je persee alleen met SSD wilt werken, ik kan niet zien wat het budget van de TS is.
Als je veel opslag wilt maar toch de performance wilt behouden (zonder direct tien duizenden euro's kwijt te zijn) is SSD cache de way to go. 7200rpm disken (die mogen stuk, kosten geen fluit) voor de echte TB's en SSD voor je write cache en extra performance.
En vergeet netwerk niet... niets is belangrijker dan lage latency (10gb/s glas) om de performance echt te kunnen halen.
Skynet ICT B.V. - The cause of the problem is: the printer thinks its a router.
23/09/16 10:59
Je denkt wat te groot :-)
We zijn het niet helemaal oneens. Jouw aanpak gebruiken we ook zeker bij een bepaald vraag. De oorspronkelijke vraag gaat niet over Terabytes maar over de manier om een cluster op te zetten met 3 of 4 nodes en een paar Tb storage. Dan heb je echt aan 1 a 2 Gbit/s aan de achterkant genoeg. En dat is ervaring, geen gok.
Als je disk uitvalt in een node met 1 disk is de situatie qua syncen gelijk aan wanneer die hele node uitvalt. M.a.w. je kun 100 disken in een node stoppen. Als je dan 3 nodes hebt en de node valt uit mis je nog steeds 1/3 van je cluster. Daarbij is het zo dat als 1 disk uitvalt dat Ceph helemaal gaat rebalancen en dus niet alleen die data van die defecte disk gaat "restoren". Dus zelfs daarmee win je niet zo veel.
Los daarvan, volgens mij past het niet in de bestaande servers die hierboven genoemd worden..
10 Gbit is vooral in dat geval wel handig maar echt niet noodzakelijk. Alleen als je vele Terabytes erop hebt staan. En zelfs dan zou je kunnen accepteren dat uitval van een node dan even wat traagheid veroorzaakt.
Wij hebben er verschillende draaien met 2 Gbit/s getrunkt. Tijdens productie geen probleem. Het haalt gewoon de snelheden die je ook haalt wanneer je aparte storage zou bouwen. Tijdens uitval van een Node zelfs ook geen problemen. Alles blijft up. Het wordt wat slugisch.
En natuurlijk duurt het rebalancen langer maar je blijft up. En alles met SSD maakt ook een hoop goed.
25/09/16 12:38
Ik heb ondertussen 6x 960GB SSD's van Samsung gekocht. De SM863 enterprise versie. Daarnaast zit er in iedere server een 10G (X520-DA2 kaart) verbinding. Elke server krijgt dus 2x 960Gb SSD's.
Ik wacht momenteel nog op H700 controllers om de Perc6I te vervangen die er nu in zit. Want die Perc6I is maar sata 3Gb/s. Niet voldoende snel dus om de SSD's optimaal te kunnen benutten.
Alle 3 servers krijgen ook 192Gb RAM, 2x L5640 CPU's en een PCI-e SSD als boot device voor proxmox.
Nu ben ik wat aan het lezen over hoe Ceph precies werkt maar klopt het dat Ceph standaard 3 kopies maakt van alle data en dat ik dus maar 6*960/3=1920Gb aan totale ruimte over heb? Is het veilig om dit terug te schroeven naar 2 kopies? Dat was blijkbaar bij Ceph vroeger de standaard. Dan zou ik 6*960/2 = 2880Gb aan ruimte hebben.
Hierop moet dus Proxmox komen met Ceph en dan zou ik toch een mini cluster moeten hebben waarop ik wat VM's kan draaien met goede performance. Toch?
Ik vroeg me trouwens ook af of ik 4x 512Gb Samsung 850 PRO + 2x 480Gb Intel 730 SSD disks ook zou gebruiken? Ik zou er in elke server zo nog 2 extra kunnen zetten, voor extra storage. Maar is dat wel verstandig want het zijn geen enterprise SSD's? .. Die enterprise ssd's zijn nu echt wat te kostelijk om er nog eens 3 extra aan te kunnen schaffen
Of kan ik met die 6x consumer SSD's een 2de ceph filesystem aanmaken voor VM's die niet zo write intensief zijn bijvoorbeeld?
Ik heb een HP Switch met 4x 10G SFP+ poorten. Deze wou ik gebruiken om de 3 servers met elkaar te verbinden. Moet alleen nog SFP+ modules en kabels bestellen.
Een cluster van 3 is nu echt wel de minimum. Ik zou er eventueel nog een 4de server aan kunnen toevoegen, maar dan gaan de hosting kosten en stroom alleen maar stijgen zonder echt een voordeel eruit te halen denk ik? En voor die 4de server heb ik dan ook minstens 2x 960GB enterprise SSD extra nodig?
25/09/16 16:27
En wat zouden jullie aanraden voor backups? Zou ik een extra server zetten met daar disks in om de backups op te zetten? Maar die staat dan ook 24/7 aan en kost ook stroom.
Of is er een beter alternatief? .. tape is niet meer van deze tijd denk ik?
25/09/16 18:18
Proxmox heeft een prima backup methode voor lokaal backup. En r1soft voor de offside backup
Op zoek naar hostingpartijen die zich willen laten overnemen (met desgewenst aanblijven)
25/09/16 23:32
Nee, want Ceph wil graag minimaal 3 servers in z'n cluster. Dan is er altijd een meerderheid als er iets gebeurt, zoals een defecte verbinding of server. Zou je een netwerkprobleem hebben met twee servers, dan kun je een split-brain situatie krijgen. En dat wil je echt niet, want dan lopen de datasets uit elkaar..
Dommel Hosting --- servers en colocatie in Eindhoven en Den Bosch
26/09/16 09:58
Je mag Ceph zeker zo instellen dat je 2 kopietjes bewaard.
Van een 4e server wordt het in principe sneller. Ik weet niet precies hoeveel je gaat doen natuurlijk. Maar qua storage zal je er niet zo veel mee opschieten. Zoals je het nu aan het bouwen bent gaat het al "Ram hard".
Die PRO's van Samsung gaan het niet goed doen. Die kakken in qua snelheid zoals eerder vermeld.
En met Proxmox en Ceph op drie servers heb je een prima cluster.
Disken mengen is voor Ceph geen probleem. Dus als je nog wat SSD's hebt liggen, stop ze erbij.
Qua backup.
Proxmox kan images maken maar doet dat wat onhandig. Daarvoor hebben we PMRB geschreven.
https://www.tuxis.nl/blog/rolling-ba...xmox-20140128/
En files doen we vaak met urbackup in combinatie met diskbayonline.nl (het is snel veel data)
Dan heb je altijd een image van de server die niet ouder is dan 1 week.
Files zet je terug met urBackup.
Als alles helemaal knalt kun je dus snel je images herstellen en recente data terug zetten.
29/09/16 12:19
Ok. De ene zegt dat het niet goed is om met slechts 2 kopies te werken terwijl de andere zegt dat het wel mag :-/
Wat is precies een split-brain situatie? En kan dat dan met 3 kopies ook voorvallen als bijvoorbeeld de switch stuk gaat?
Ja, eigenlijk vraag ik me wel af hoe Ceph zal reageren stel dat een switch defect gaat? Of als er een server down gaat en daarna terug wordt herstart. Zal Ceph dan de server gewoon terug aanvaarden en terug syncen, of wat zal er dan gebeuren?
29/09/16 14:09
Ik zal het proberen toe te lichten met het voorbeeld van drie nodes en beperk het even tot het gedrag van Ceph.
Stel je sluit 3 nodes aan op 1 switch. Switcht stuk = cluster stuk. Niets nieuws voor zover (hoop ik :-) )
Als we dan kijken wat er gebeurt als één node uitvalt.
In het geval van 1 duplicaat zorgt Ceph ervoor dat het duplicaat altijd op een andere plek staat. Dat bepaal je in de crushmap. Dus datacenter, server, disk.
Dan is 1 duplicaat dus al een betere situatie dan RAID 1 (mirror). Want in dat geval is storing aan een controller al een probleem.
In het geval van Ceph betekent uitval van 1 node een degredatie van de redundantie maar nooit verlies van data. Ceph gaat rebalancen, dus zorgen dat er weer 1 duplicaat is.
Wanneer de node weer op komt, gaat hij weer rebalancen.
Natuurlijk mag je aangeven dat hij 2 duplicaten moet maken. In dat geval zou op iedere node alle data staan. Dan gaat hij alsnog rebalancen als er een node uitvalt en het dan zorgen dat data niet 2x op dezelfde disk staat (want met 2 nodes en data 3x hebben ga je data dubbel op een node hebben staan).
En dat maakt het tevens een beetje onzinnig naar mijn idee. Je vangt er op zijn best nog een uitval van een disk mee af op het moment dat er een node stuk is.
Dus node stuk en daarna een disk stuk in een node net voor hij klaar is met rebalancen...
Iets met kansberekening.
Split brain komt bij Ceph niet voor. Ceph stopt altijd met werken als hij de monitors niet meer ziet.
Het komt voor wanneer je iets bouwt met 2 nodes of locaties en je die twee onderling laat kijken of ze live zijn.
Laten we uitgaan van 2 nodes.
De gedachte is: Iedere node kijkt of hij de andere nog kan zien. Als hij dat niet kan maar hij ziet de rest van de wereld wel (het internet) dan is hij de baas. Er zijn echter situaties denkbaar waarbij beide nodes de andere node niet ziet maar wel internet hebt.
Dan heb je dus twee nodes die beide live zijn. En als dan de helft van de klanten in een database zitten te klikken op een VM op de ene node en de andere helft van je klanten in dezelfde database zitten te klikken op "dezelfde" VM in de andere node ben je de sjaak.
Je hebt twee delen die beide de baas denken te zijn. Twee slimme systemen... split brain.
De oplossing is simpel: 3 nodes (of een ander oneven aantal). Ziet een andere node nog 1 andere node dan weet hij dat ze met zijn tweetjes zijn en die ene weg is en zij met zijn tweetjes actief zijn. Ziet hij geen andere node, dan weet hij dat hij alleen is en niets mag doen.
Zie ook: https://en.wikipedia.org/wiki/Split-brain_(computing)
Soms wordt er als 3e node een monitor in de lucht gebracht in plaats van een hele node.
Likes: 
Quote