RAID configuratie 36 disks

[marco208]

Beste Tweakers,

Ik ben opzoek naar een oplossing om een snelle stabiele samenstelling van 36 disks in een SuperMicro chassis tot 1 "disk" te krijgen in linux. Ik kom alleen niet veel verder aangezien de grootste RAID controller 32 channels lijkt te hebben.

Er komen backups op te staan, heel veel data. De lees en schrijfsnelheid zijn van belang dus we dachten eraan om RAID-60 of 50 tegebruiken met SATA disks van 2 of 4TB gemount als EXT4 filesystem in linux.

ZFS hebben we al geprobeerd alleen na erg veel tweaken hebben we het opgegeven aangezien dit niet fijn werkte voor wat we willen (werkt overigens verder prima als SAN)

Ik had deze kaart gevonden voor 32 channels:
http://azerty.nl/8-1640-9...raid-52445-storage-c.html

Hebben jullie enige ideeën om ons een stapje verder te helpen?

Alvast bedankt!

groetjes, Marco

[wagenveld]

Ik zou hier eens beginnen voor inspiratie:
http://blog.backblaze.com...brations-storage-pod-3-0/

Sowieso zul je meerdere (simpele) controllers willen gebruiken lijkt mij.

[PeterPan]

Afhankelijk van de performance die je wenst zou je kunnen kiezen voor een eenvoudigere RAID controller met minder channels en gebruik maken van SAS expanders (HP en Intel hebben betaalbare SAS expanders). Op hardforum.com kun je hier bijvoorbeeld veel informatie over vinden.

Of geen RAID controller maar een aantal normale multi poort SATA controllers en software RAID gebruiken onder Linux.

Met 2TB+ disks zou ik niet meer kiezen voor RAID5/RAID50 maar minimaal drie RAID6 sets in RAID60 (gevoelsmatig). Je zou eens kunnen onderzoeken wat storage vendors doen met grote storage bakken. EqualLogic zet bijvoorbeeld een 24 disk systeem in twee RAID6 sets (in RAID60 dus) met een global spare.

[ Voor 9% gewijzigd door PeterPan op 29-01-2014 16:51 ]

[M2M]

Als het om zoveel data gaat, is het misschien een handig idee een professional te raadplegen? Zeker als het om (wellicht kritische) bedrijfsdata gaat...

[vlaaing peerd]

Dat is best een prijzige kaart en loopt nog op 300gbps. Had toevallig net een kaart op basis LSI SAS2208 in handen, gaan tot 128 disks en zijn volgens mij al snel een euro of 400 minder én loopt op 600Gpbs.

Maarre, SMC heeft toch van die mega-Hadoop-bakken met bulten schijven erin? Hebben ze dan niet meteen een passende RAID oplossing erbij?

[Paul]

Ik zou, als ZFS inderdaad niks is, vanwege het aantal disks gewoon 'domme' controllers gebruiken en LVM + MDADM (en zorgen dat er genoeg RAM in de machine zit).

Echte raidcontrollers kan ook, maar dan moet je inderdaad of een model hebben dat zoveel poorten heeft, of een die expanders aan kan i.c.m. SATA, of meerdere die samen kunnen werken. Doe je dat niet dan heb je straks 5 hot spares of arrays zonder hot spare...

Mag ik vragen waarom ZFS niet is wat je zoekt? Onder Linux schijnt de implementatie niet alles te zijn (al heb ik daar zo snel geen bron bij) maar onder BSD werkt het uitstekend. Het wegschrijven van backups zou geen enkel probleem moeten zijn, hooguit wanneer je alles als sync write forceert dat je er een fatsoenlijk SLOG bij wilt...

Edit: Lees de handleiding van je chassis! Het chassis heeft al expanders op de backplane, je hebt een (raid)controller met 2x SFF 8087 nodig! Een simpele HP SmartArray P410 of zo voldoet al...

[ Voor 39% gewijzigd door Paul op 30-01-2014 11:21 ]

[The_Greater]

Splits het op in twee servers. Backup en werk data.
Voor de backup zou je een mindere excotische raid opstellingen kunnen gebruiken.

Je weet dat je veel capaciteit je verliest met RAID 50/60?
Is het niet mogelijk om meerdere RAID5/6 SETS aan te maken?

[Rolfie]

Is misschien FreeNAS niet gewoon een goede oplossing?
Werkt op basis van ZFS icm met FreeBSD. Wordt goed ontwikkeld en werkt heel goed.
Bijna alles kan je via de webinterface doen, en is getuned voor performance.

Is dit geen oplossing voor jullie?

[Jolke]

36 disken!?

Is alle data daarvan ook daadwerkelijk running/active data? Het lijkt me (persoonlijk) prettiger om meerdere systemen te hebben. Mocht er een dan een systeem down gaan, is niet meteen alles down. Bovendien win je hiermee performance als je zaken scheidt.

[Anoniem: 15758]

Welke disks ga je gebruiken?

Wat wil je precies bereiken; welke eisen stel je aan betrouwbaarheid en corruptievrije opslag?

Wat is precies de reden dat ZFS voor je afvalt? Voor backups is ZFS erg nuttig vanwege de incremental snapshots en natuurlijk checksum bescherming.

Al neem je geen ZFS, dan kun je meerdere HBA controllers en software RAID overwegen. Dat lijkt me nog beter dan hardware RAID op één controller; dan heb je een enkele point of failure en een kaart die je niet 1-2-3 kunt vervangen. Een reserve HBA voor 8 tientjes op de plank laten liggen is dan wellicht een beter alternatief.

[marco208]

Wow hartstikke bedankt voor jullie reacties!

wagenveld: Dankje! Die ga ik zometeen even uitgebreid lezen!

PeterPan: We hebben wel wat performance nodig aangezien we 130 servers á 350GB per stuk willen backuppen elke nacht op incrementele methode (5/6GB per dag gemiddeld per server). De CPU's hebben we nodig voor compressie dus die kunnen we niet belasten. We zijn bekend met equallogic, we draaien er hier 4 van, echter zitten in deze chassis meer disks dus zat ik een, daar voor, beter opstelling te zoeken raid 60 lijkt me prima! Dankje voor je reactie!

M2M: We zijn zelf er ook wel goed mee hoor! Echter willen we graag van anderen horen wat zij daar van denken Zo leren we het zelf ook!

vlaaing peerd: De controller die erin zit is erg slecht... Support tot 8 disks dacht ik in raid, de rest word gezien als losse disks. Of doen we iets verkeerd? Ik ga me even verdiepen in de kaart die jij me aangaf. En zal rekening gaanhouden met de 600Gbps!


Paul: Dat hadden we inderdaad al gezien dat er een SAS expander inzat, ik wist zelf echter neit dat ik dan met 2 controllers al klaar zou zijn! Ga ik ook even naar kijken. Verder was ZFS prima, maar de snelheid van Idera Backup ging hard achteruit aangezien de blocksize die idera gebruikt 4k was en ZFS 128k. In vergelijking tot de raid controller van het chassis zelf is de performance echt slecht. Als SAN dient het nogsteeds prima (naast onze equallogics). LVM met MDADM, dit heb ik eigenlijk nog nooit geprobeerd, ik ga is een test opstelling maken hiervoor!

The_Greater: De bedoeling is dat de backups bewaart blijven, dus RAID 1 moet sowieso. Ik weet dat we dan veel ruimte weg gooien, maar dat haalt ons niet over om mirroring niet te doen ;)! Verder hebben we zeer krachtige opstellingen staan voor actieve data, dat is verder niet door de backups gehaald.

Rolfie: Nee helaas, was het maar zo simpel. ZFS werkt niet voor ons.

Jolke: De bedoeling is ook om 2 exact de zelfde systemen te maken en de data de dupliceren naar een ander datacenter. Het is alle data de we actief hebben in hoogste compressie . Niks is actief, het is geen critical als de server uitvalt, de data daarintegen wel, maar kan tijdelijk weg zijn, anders hadden we voor een duurdere oplossing kunnen kiezen als EqualLogic

CiPHER: Goeie vraag, we zijn alleen nog bezig geweest met het transport. Ik denk aan deze als we 2TB per disk gaan:
http://azerty.nl/8-857-45...arracuda-st2000dm001.html
ZFS werkte niet met de software die willen gebruiken, dit vanwege de blocksizes en ook dat de software alleen op CentOS draait, dat i.c.m. ZFS is niet erg fijn.


Nogmaals bedankt voor alle reacties!

[_JGC_]

Je hebt helemaal geen dure RAID controller met 36 channels nodig, de 36 bay chassis van Supermicro werkt met 2 backplanes van 12 en 24 bays. Beide backplanes hebben een multilane SAS connector.

Als je de 847E16 gaat gebruiken heb je de keuze uit een 4 poorts SAS controller waarbij je de backplanes gaat daisychainen of aan een 8 poorts SAS controller waar je de backplanes elk op een eigen connector doet.

Ik heb zelf de 24 poorts versies van die behuizingen op een LSI 3Ware 9750-8i draaien, de ene poort hangt aan de backplane van de server, de andere poort gaat via convertor bracket en externe kabel via nog een convertor bracket naar een 24 poorts behuizing met alleen een power card.

Overigens, 36 disks in 1 RAID array moet je gewoon niet willen. Foutgevoeligheid bij zulke grote arrays wordt veel te groot, vraag me af of RAID6 je genoeg gaat beschermen.

[Paul]

marco208 schreef op donderdag 30 januari 2014 @ 09:50:
In vergelijking tot de raid controller van het chassis zelf is de performance echt slecht.

Het chassis heeft helemaal geen raidcontroller? Het heeft geen enkele vorm van HBA of intelligentie, het kan alleen 24 bays multiplexen naar één SAS-connector van 4 kanalen

RAID 1 moet sowieso

RAID 1 doe je al door een 2e machine in een ander DC te zetten en daar naartoe te repliceren. Dat zou ik dus binnen het chassis niet nog een keer doen voor je data.

Ik zie overigens ook dat het chassis alleen low-profile kaarten slikt? pricewatch: LSI SAS 9207-8i is de goedkoopste low profile kaart met 8x SAS2 en de aansluitingen aan de achterkant.

2x 160 GB (of whatever tegenwoordig goedkoop is) voor je OS in (MDADM) RAID 1, 1 schijf hot spare, 1 of 2 schijven cold spare, 4x RAID6 van 8 schijven. Dit in LVM om het geheel samen te voegen tot 1 geheel. Dit is je raid 0, maar in tegenstelling tot het vast instellen van een RAID0 kun je nu nog uitbreiden als je besluit niet met een vol chassis te beginnen, of kun je er een array verwijderen om er grotere schijven voor terug te plaatsen.

ZFS werkte niet met de software die willen gebruiken, dit vanwege de blocksizes en ook dat de software alleen op CentOS draait, dat i.c.m. ZFS is niet erg fijn.

Block size zou geen probleem moeten zijn, er komen zoveel blokjes van 4K aan dat het makkelijk blokken van 128K vol krijgt om die weg te gaan schrijven... Verschil in OS kan wel een issue zijn... Eén ZFS-doos en daar bovenop een losse backup-doos (en een paar pricewatch: Intel X540-T1 er tussen) is zeker geen optie? Dan heeft de proc in de ZFS-doos zijn handen vrij om te dedupliceren (wat bij backups heel erg goed kan) https://pthree.org/2012/1...ession-and-deduplication/

Ik kom boven met mijn schijven uit op 35 schijven ipv 36. De 36e kun je inzetten als 2e hot spare of met een snelle SSD als L2ARC. Dedup kost wel klauwen met RAM, maar voor de prijs van 1 harde schijf kun je ook 16 GB ram kopen, en 4 TB op de 90 heb je al snel terugverdiend met dit soort data @work gebruiken we CommVault, die dedupt ook. We halen daar 1:5 ongeveer

[marco208]

Helaas werkte ZFS echt niet goed, ik heb er weken aan verspilt om het werkend te krijgen maar het is helaas niet gelukt. LVM later samen voegen dan krijg je toch 1 set die heel druk is en de andere niet?

Ik heb juist geprobeerd OpenIndiana te draaien met een iscsi verbinding naar een CentOS server, dit viel tegen qua performance omdat voornamelijk telkens 1 disk heel druk begon te zijn... Dat is nu met hardware RAID afgelopen. De kaart die jij gaf kan geen raid 6 maken toch? het liefst doe ik wel RAID-60, DC replicatie komt pas later.

2 raid controllers die 16 disks in RAID-60 zetten en die in LVM met MDADM RAID-0? Is dit een goede opstelling dan?

[vso]

Anoniem: 15758 schreef op woensdag 29 januari 2014 @ 17:39:
Wat is precies de reden dat ZFS voor je afvalt? Voor backups is ZFS erg nuttig vanwege de incremental snapshots en natuurlijk checksum bescherming.

oftewel "raid bitrot" .. hoe meer GB je op een disk hebt en met HW/SW raid hoe groter de kans op fouten in je data. hierom kan je beter met meer kleinere disks werken. (kans is klein though maar neem je dit risico)

Al neem je geen ZFS, dan kun je meerdere HBA controllers en software RAID overwegen. Dat lijkt me nog beter dan hardware RAID op één controller; dan heb je een enkele point of failure en een kaart die je niet 1-2-3 kunt vervangen. Een reserve HBA voor 8 tientjes op de plank laten liggen is dan wellicht een beter alternatief.

Hier ben ik het wel met Cypher eens, SW raid bied meer voordelen, daarnaast meen ik me te herrineren dat ZFS wel een tijd nodig heeft voordat het optimaal werkt.

Kijk eens naar puppet, bv freenas/ZFS guru op een SD kaart/USB stick (intern) is snel uitgerold + geconfigureerd met puppet.

Ik zou bv 8 of zelfs 10 systemen nemen dan 1 grote, reduceer de single point of failure.
Maar goed dan kom je met andere facetten in de "knel"

Laatst bij een klant gezien waarbij een IT bedrijfje 2x zelfbouw nas in sync opstelling had gezet, in theorie was het erg mooi totdat na 1 jaar de boel hard onderuit ging, bedrijf 2 dagen plat .. oorzaak bleek te zijn dat de gebruikte technologie-en niet altijd even vriendelijk is .. versie verschil en andere "kleine" foutjes die men over het hoofd had gezien ..

Tenzij je tijd gratis is, zou ik met de tijd die reeds besteed hebt kiezen voor een goeie storage oplossing bij een groot (gespecialiseerd merk) .. het kan aardig wat geld kosten als je een claim op je dak krijgt omdat data corrupt/missend is, en puur omdat je niet goed je backup oplossing getest hebt en iemand zei "het kan wel"

[Anoniem: 15758]

marco208 schreef op donderdag 30 januari 2014 @ 15:32:
Helaas werkte ZFS echt niet goed, ik heb er weken aan verspilt om het werkend te krijgen maar het is helaas niet gelukt.

Ik wil je niet pushen verder maar dit soort uitspraken vermoed ik dat je ZFS helemaal geen echte kans hebt gegeven. Wat er 'niet gelukt' is laat je ook in het midden. Laat duidelijk zijn dat het configureren van een ZFS NAS ongeveer 5 minuten kost en je dan een werkende ZFS NAS hebt. Samba toegang hoef je ook weinig aan te doen.

Heb je speciale wensen/eisen en kreeg je dat niet werkend met ZFS, oke daar valt misschien wat voor te zeggen. Maar ZFS is zowat het gemakkelijkst te configureren opslagplatform, zeker als je een van de vele operating systems / appliances gebruikt die speciaal voor ZFS geschreven zijn.

Juist voor een grote backup server met redundancy is ZFS uitstekend geschikt. Dit omdat je met checksums weet of data corrupt is of niet, en met snapshots kun je heel economisch, snel en makkelijk incremental backups maken.

Het alternatief met Hardware RAID en 36 disks betekent dat je hele array kwijt kan zijn door uBER bad sectors, waarbij meerdere schijven uit de RAID set worden gegooid en je weinig hebt aan je RAID6/ Mirror bescherming.

Wil je toch betrouwbaarheid maar dan geen ZFS, dan moet je flink de portemonnee trekken:

• Enterprise hardeschijven met uBER spec van 10^-16 = erg duur. Zoals deze: pricewatch: Seagate Enterprise Performance 10K.7 Encryption ST1200MM0017, 1.2TB
• Dure controller die hardware RAID6 ondersteunt
• Battery Backup Unit voor bescherming van RAID5/RAID6 write-back
• UPS voor bescherming van onveilige host write-back

vso schreef op donderdag 30 januari 2014 @ 16:30:
oftewel "raid bitrot" .. hoe meer GB je op een disk hebt en met HW/SW raid hoe groter de kans op fouten in je data. hierom kan je beter met meer kleinere disks werken.

Of juist met duurdere disks met uBER van 10^-16. Dan heb je - in elk geval op papier - een factor 100 minder kans op bad sectors door onvoldoende errorcorrectie (uBER bad sectors). Tenminste 10^-15 als het even kan, de 10^-14 disks zijn eigenlijk ongeschikt voor legacy RAID.

[redfoxert]

Al eens gekeken naar Avamar als backup solution van EMC?

Source based dedup dus je backupped in feite maar heel weinig, zeker als je incremental backups gebruikt.

[Paul]

MDADM is software raid, die controller hoeft dus geen RAID aan te kunnen. Of het eerst aan de ene disk / array en dan pas aan de volgende begint hangt er vanaf hoe je het inricht: http://www.linux-mag.com/id/7582/

[Mysteryman]

Anoniem: 15758 schreef op donderdag 30 januari 2014 @ 17:23:
[...]

een heel goed verhaal!


[...]

Als je geen ervaring hebt met ZFS, kan ik je tenzeerste dit artikel op HowToGeek aanraden. Dat geeft een goed beeld van de voordelen en mogenlijkheden van ZFS!

[Q]

marco208 schreef op donderdag 30 januari 2014 @ 15:32:
Helaas werkte ZFS echt niet goed, ik heb er weken aan verspilt om het werkend te krijgen maar het is helaas niet gelukt.

Ik vraag me echt af of ZFS toch niet goed aan de praat te krijgen is. ZFS werkt met een dynamische block size van 128K max maar kleinere block sizes kan ook prima. Sync writes al eens uitgeschakeld?

ZFS kan ook zo 'schattig' snapshots syncen over het internet naar een andere array, echt super gaaf allemaal. En dat checksumming vind ik een killer feature.

Als je toch echt de MDADM route wilt opgaan, kies dan voor het XFS file system omdat deze over de 16 TB partitie grens heen kan gaan, EXT4 naar mijn weten (nog steeds niet) qua user land tools (dubbelcheck dit).

MDADM RAID + LVM: Ik denk dat het makkelijker is om meerdere RAID6 arrays samen in een RAID0 te stoppen, waarbij de RAID0 dan wel een wat grotere chunk size moet hebben om van de performance van je RAID6 te kunnen genieten.

Dit heb ik nooit getest, maar ik zou zeggen 64 KB chunk size voor de RAID6 en 64k x aantal RAID 6 arrays wat je hebt of groter. dus 2 x RAID6 = 128 K chunk size voor RAID60 setup.

Of dit goed werkt: leuke benchmark!

[ Voor 32% gewijzigd door Q op 30-01-2014 20:06 ]

[Rolfie]

marco208 schreef op donderdag 30 januari 2014 @ 09:50:
PeterPan: We hebben wel wat performance nodig aangezien we 130 servers á 350GB per stuk willen backuppen elke nacht op incrementele methode (5/6GB per dag gemiddeld per server). De CPU's hebben we nodig voor compressie dus die kunnen we niet belasten. We zijn bekend met equallogic, we draaien er hier 4 van, echter zitten in deze chassis meer disks dus zat ik een, daar voor, beter opstelling te zoeken raid 60 lijkt me prima! Dankje voor je reactie!

Misschien ook even kijken of je bandbreedte van de raid controllers een limiterende factor gaat worden?
Idem voor je netwerk. Maar je SATA bus zou ook wel eens een limiterende factor kunnen worden.

RAID5 or RAID6 zijn zwaar voor je controllers. Juist 1 van de grote voordelen van ZFS. Onboard compressie en indien gewenst deduplication (al kost je dat heel veel geheugen.

Rolfie: Nee helaas, was het maar zo simpel. ZFS werkt niet voor ons.

Een echte redenen geef je niet. Terwijl juist ZFS gemaakt is voor wat je zoekt. Zeker met zoveel data is ZFS een krachtige tool wat je met andere bestandsformaaten niet voor elkaar krijgt. Zeker als je ook nog eens SSD's gaat gebruiken voor caching. [/q]

[Mijzelf]

Ik lees als vuistregel voor ZFS dat je 1GB ram nodig voor 1TB opslag. Dus met 36 schijven van 3TB en behoorlijke redundantie zou je al gauw 50GB nodig hebben. Klopt dat?

[EnerQi]

Mijzelf schreef op vrijdag 31 januari 2014 @ 11:17:
Ik lees als vuistregel voor ZFS dat je 1GB ram nodig voor 1TB opslag. Dus met 36 schijven van 3TB en behoorlijke redundantie zou je al gauw 50GB nodig hebben. Klopt dat?

In enterprise omgevingen is/kan dit een stelregel zijn, die hebben met vele gebruikers natuurlijk een ander patroon dan thuis. Voor huis/tuin/keuken gebruik telt ie niet . Begin met 32 GB ram en als dat niet genoeg is, doorgaan naar 64GB? Overigens zou ik (als ik het heb liggen tenminste) met 16 GB beginnen. Volgens mij zou dat ook nog genoeg zijn. Als ik toch alles opnieuw moet bestellen: 32 GB.

[Q]

Mijzelf schreef op vrijdag 31 januari 2014 @ 11:17:
Ik lees als vuistregel voor ZFS dat je 1GB ram nodig voor 1TB opslag. Dus met 36 schijven van 3TB en behoorlijke redundantie zou je al gauw 50GB nodig hebben. Klopt dat?

Wat EnerQi zegt + voor thuis gebruik is 8 GB waarschijnlijk al zat. Weinig concurrent gebruikers, veel meer archivering dan high-performance. Zo blijft het ook een beetje betaalbaar.

In dit geval is er meer budget, maar meer dan 16 GB RAM lijkt mij niet eens nodig met een 36 disk setup, omdat het als archivering / backup oplossing wordt gebruikt.

[ Voor 19% gewijzigd door Q op 31-01-2014 12:51 ]

[Ultimation]

Ik zou gelijk een bord als deze halen:

pricewatch: Supermicro X9DRi-F

Dan kan je door tot 1Tb aan intern geheugen!

[Paul]

De setup in dit topic gaat echter niet in een thuissituatie gebruikt worden En 64 GB ram (ECC registered) kost ongeveer een derde van de RAID-controller die gelinkt wordt

Ultimation: Dan zou ik de X9DR7-LN4F-JBOD nemen, dan hoef je de backplanes niet te chainen. Of, als je 10GE wilt, de X9DR7-TF+ (en SuperMicro bellen voor de SKU die meer dan 16 schijven aan kan op de 8p SAS-controller).

[ Voor 38% gewijzigd door Paul op 31-01-2014 13:18 ]

[vlaaing peerd]

Of kijk's naar een ander merk.

[Anoniem: 15758]

Mijzelf schreef op vrijdag 31 januari 2014 @ 11:17:
Ik lees als vuistregel voor ZFS dat je 1GB ram nodig voor 1TB opslag. Dus met 36 schijven van 3TB en behoorlijke redundantie zou je al gauw 50GB nodig hebben. Klopt dat?

Dat is niet correct.

De 'vuistregel' is verkeerd; ZFS heeft niet meer RAM-geheugen nodig als de schijven groter worden. ZFS heeft meer geheugen nodig als de schijven sneller worden. Dus het zou beter zijn als je zou stellen dat je per 200MB/s performance 1GB RAM nodig hebt, al zijn dat ook wel heel ruwe schattingen. De praktijk is gewoon dat je niet minder dan 8GB wilt hebben voor een ZFS server die ook een beetje snel moet presteren. Aangezien het hier om backup gaat, denk ik dat 8GB wel genoeg is. 16GB zou ook kunnen omdat het zoveel disks zijn en misschien meer dan gigabit gebruikt gaat worden.

[DukeBox]

Paul schreef op woensdag 29 januari 2014 @ 16:55:
Een simpele HP SmartArray P410 of zo voldoet al...

Gaat die over de physical 2TB dan ? Volgens mij is het max logical volume ook beperkt.

[Paul]

vlaaing peerd schreef op vrijdag 31 januari 2014 @ 13:52:
Of kijk's naar een ander merk.

Zoveel Intel of Tyan staat er niet in de PW helaas, en op de site van SM kun je makkelijk(er) vergelijken dan bij Tyan Intel nog niet geprobeerd.

Verder ken ik eigenlijk niet echt fabrikanten van serverboards... MSI, Gigabyte, Asrock, Asus, dat zijn toch meer consumentenbordjes...

DukeBox schreef op vrijdag 31 januari 2014 @ 13:55:
[...]

Gaat die over de physical 2TB dan ? Volgens mij is het max logical volume ook beperkt.

Yup: http://h18004.www1.hp.com.../questionsanswers.html#8b Al valt er weinig concreets over te vinden...

Alleen zie ik nu dat de 410 maar 24 (of op sommige plaatsen zelfs 12) schijven ondersteunt

[vlaaing peerd]

Paul schreef op vrijdag 31 januari 2014 @ 14:05:
[...]
Asus, dat zijn toch meer consumentenbordjes...

Ik doe m'n best er geen reclame voor te maken, maarrehh de heren van Asus zijn zo'n beetje OEM producent van alles wat je op een PCB kan printen.

kijk 's naar deze server of dit bord . Dat moet wel voldoen aan je eisen.

[_JGC_]

Paul schreef op vrijdag 31 januari 2014 @ 13:06:
De setup in dit topic gaat echter niet in een thuissituatie gebruikt worden En 64 GB ram (ECC registered) kost ongeveer een derde van de RAID-controller die gelinkt wordt

Ultimation: Dan zou ik de X9DR7-LN4F-JBOD nemen, dan hoef je de backplanes niet te chainen. Of, als je 10GE wilt, de X9DR7-TF+ (en SuperMicro bellen voor de SKU die meer dan 16 schijven aan kan op de 8p SAS-controller).

In plaats van een specifiek bord met onboard SAS kan je ook gewoon een LSI 9211-8i of een IBM M1015 (die je flasht naar een 9211-8i in IT mode) nemen.

De onboard SFF interface van de X9DRI-F zou ik persoonlijk niet gebruiken, 24 of 36 disks via een 4x300MB/s connectie is vragen om bottlenecks. Verder is LSI zo ongeveer de standaard als het op SAS aankomt, de expander in die supermicro kast heeft een LSI expander chipset, daarvan weet je ook zeker dat het getest is op een LSI HBA. Of zoiets goed werkt met de Intel SCU is nog maar de vraag.

[DXaroth]

marco208 schreef op woensdag 29 januari 2014 @ 16:37:
Beste Tweakers,

Ik ben opzoek naar een oplossing om een snelle stabiele samenstelling van 36 disks in een SuperMicro chassis tot 1 "disk" te krijgen in linux. Ik kom alleen niet veel verder aangezien de grootste RAID controller 32 channels lijkt te hebben.

Er komen backups op te staan, heel veel data. De lees en schrijfsnelheid zijn van belang dus we dachten eraan om RAID-60 of 50 tegebruiken met SATA disks van 2 of 4TB gemount als EXT4 filesystem in linux.

ZFS hebben we al geprobeerd alleen na erg veel tweaken hebben we het opgegeven aangezien dit niet fijn werkte voor wat we willen (werkt overigens verder prima als SAN)

Ik had deze kaart gevonden voor 32 channels:
http://azerty.nl/8-1640-9...raid-52445-storage-c.html

Hebben jullie enige ideeën om ons een stapje verder te helpen?

Alvast bedankt!

groetjes, Marco

Waarom '36 disks'? uit je posts begrijp ik dat je nog niet echt weet -wat- voor disks (en dus ook niet formaat), dus waarom weet je wel de hoeveelheid? is dat omdat je het chassis al hebt? of omdat er andere eisen zijn?

Als je een fixed size opslag wilt hebben (stel: 50TB effectief), dan kan je eventueel ook met 32 disks uit de voeten, waarbij de overige 4 gebruikt worden voor het OS (2 disks) en 2 spare slots.
om 50TB uit 32 disks te halen ga je op zn slechts RAID10 draaien, dus dan moet je uit 32 disks 100TB ruimte halen.. 3TB disks zijn haalbaar.. en op een wat optimalere (een RAID60 bv) setup heeft minder overhead, waarmee je met 2TB disks al de 50TB effectief haalt.

Er van uitgaande dat je supermicro neemt; je weet dat die ook specifieke storage chassis hebben, waar dus al iets van SAS in zit? dan heb ik het over systemen als deze:
http://www.supermicro.com.../847/SC847E26-R1400LP.cfm

[Anoniem: 15758]

Als 50TB de streefcapaciteit is, dan zou met 2x RAID-Z2 10-disks al op (20 - 4) * 4TB = 64GB bruikbare opslag kunnen komen. Met slechts 20 poorten, dat kun je al bereiken met één 16-poorts HBA en 4 op de onboard controller, met de overige twee voor het operating system in mirror, bijvoorbeeld.

Er zijn veel mogelijkheden, als je flexibel bent en niet vastzit aan bestaande hardware e.d.

[marco208]

Sorry, ik was even een tijdje afwezig. ZFS heb ik maanden lang gebruikt maar bleef tegenvallen, ik heb geen idee waarom... Maar als je het wilt testen kan dat! ZFS is gratis en Idera heeft een trial key.

De full backup ging altijd goed, maar incremental block diff sync loopt hij vast, ZFS werd super druk en kon het lezen en schrijven tegelijk niet aan... We hadden er 64GB ram in zitten het chassis hebben we al, er zitten nu 18 x 1TB disks in, dit waren eerst 2 RAIDZ-3 pools

Maarrrr... Ik ga het nog een keer overleggen dan als jullie er zeker van zijn dat het moet werken. Misschien kopen we dan wel eerst de disks en als het nog niet werkt de controllers

[Mysteryman]

marco208 schreef op maandag 03 februari 2014 @ 15:01:
Sorry, ik was even een tijdje afwezig. ZFS heb ik maanden lang gebruikt maar bleef tegenvallen, ik heb geen idee waarom... Maar als je het wilt testen kan dat! ZFS is gratis en Idera heeft een trial key.

De full backup ging altijd goed, maar incremental block diff sync loopt hij vast, ZFS werd super druk en kon het lezen en schrijven tegelijk niet aan... We hadden er 64GB ram in zitten het chassis hebben we al, er zitten nu 18 x 1TB disks in, dit waren eerst 2 RAIDZ-3 pools

Maarrrr... Ik ga het nog een keer overleggen dan als jullie er zeker van zijn dat het moet werken. Misschien kopen we dan wel eerst de disks en als het nog niet werkt de controllers

Als je disks koopt, dan is het geen miskoop als je een aantal SSD's koop waar je ZFS cache disks van kan maken... Die cachen namelijk veel gebruikte bestanden.

Tevens kan je hier eens kijken voor tricks en tips

[Q]

Mysteryman schreef op maandag 03 februari 2014 @ 17:59:
[...]


Als je disks koopt, dan is het geen miskoop als je een aantal SSD's koop waar je ZFS cache disks van kan maken... Die cachen namelijk veel gebruikte bestanden.

SSD is 100% niet nuttig voor de toepassing van Marco208 zoals ik het nu inschat.

Wat ik wel ruik is dat een diff blijkbaar continue leest + schrijft en feitelijk Random I/O geeft.

1 VDEV geeft de random I/O performance van 1 disk dus als je 1 a 2 grote RAIDZ3's vdevs maakt dan is het niet geheel vreemd dat de diff totaal inkakt.

Je hebt best kans dat je een hele reeks RAIDZ1's of zelfs gewoon een reeks mirror's in een pool moet stoppen om genoeg random I/O's uit je disks te kunnen slaan met ZFS. Een probleem wat je mogelijk niet hebt met MDADM dat geeft redelijke random I/O op arrays.

Met 130 VMs * 6 GB per dag zit je zo op 780 GB wat je even moet verwerken, als er dan ook meerdere processen tegelijk lopen: random I/O galore.

Je wilt natuurlijk wel weten of je backup files niet corrupt zijn opgeslagen, maar de backup server kan natuurlijk altijd een verify doen. Dan MDADM + LVM (optioneel) + XFS zou genoeg kunnen zijn.

En ZFS op een MDADM array heeft als voordeel dat je goedkoop kunt snapshotten en nog steeds door checksums in ieder geval wordt geinformeerd als een bestand corrupt is. Dat kan al waarde hebben.

[ Voor 23% gewijzigd door Q op 03-02-2014 19:08 ]

[Paul]

Met 6x 3-disk Z1 heb je evenveel 'verlies' aan schijven als met 2x Z3, maar wel 3x zoveel IOPs.

Als de IOPs (en dan vooral reads) inderdaad echt random zijn dan gaat geen caching daarbij helpen, dus ook een SSD niet.

[Q]

Precies en met 36 disks zeg per stuk 2 TB kun je met een verlies van 1/3 van de capaciteit door RAIDZ1's te gebruiken als VDEVS zou je 48 TB storage kunnen hebben met de IOPS van 12 vdevs x 75 iops single disk = ~900 IOPS.

Ik noemde MDADM wel als optie maar de random IO van een RAID5 en RAID6 qua writes is ook slecht

http://louwrentius.com/be...ifferent-raid-levels.html

[ Voor 35% gewijzigd door Q op 03-02-2014 20:58 ]

[ppl]

marco208 schreef op donderdag 30 januari 2014 @ 09:50:
ZFS werkte niet met de software die willen gebruiken, dit vanwege de blocksizes en ook dat de software alleen op CentOS draait, dat i.c.m. ZFS is niet erg fijn.

Je kunt CentOS/Red Hat/Fedora spul draaien in een jail op een FreeBSD machine (hun Linux compatibility laag stoelt daar namelijk op) en die jail weer op zfs. Daardoor heb je en een fatsoenlijke zfs ondersteuning en een systeem waarop de backup software draait.

Je kunt het natuurlijk ook scheiden: maak een SAN bedoelt voor backups en draai de backup software op een andere machine. Je biedt dan via een LUN of NFS de storage op de SAN aan de backup server aan. Dat geeft ook een flexibeler setup omdat je storage en backupsoftware gescheiden houdt. Mocht je 1 van de twee wisselen dan is dit zo wat makkelijker. Je kunt op deze manier ook meer dan 1 backup server gebruiken (denk aan het draaien van verschillende backup software).

Andere optie is kijken naar distributed filesystems. Dan bouw je een netwerk van storage servers op. Dat heeft ook zo zijn voordelen en nadelen. Ceph is daar een voorbeeld van en is op dit moment erg populair (gezien de leeftijd is het echter een beetje de vraag of het verstandig is om die voor productie te gaan gebruiken, gelukkig bestaat er meer dan Ceph).

En ja, uiteraard is het ook een optie om een kant-en-klare oplossing te kopen maar volgens mij was dat nou net niet je bedoeling. Besef je wel dat je hier wel een systeem kunt aanschaffen die datgene doet wat het moet doen en waar je een berg support op kunt krijgen. Bij homebrew spul is dat nog maar de vraag. Je zult wel iets achter de hand moeten houden voor wanneer het mis gaat.

Tot slot nog een open deur: je kunt het ook de andere kant op redeneren: misschien eens kijken naar backupsoftware dat wel goed werkt met de storage omgeving die je wilt bouwen/hebt. Is makkelijker gezegd dan gedaan.

[marco208]

Ok, een mirrored pool maken van de 34 disks 2 in spare op ZFS lijkt jullie dus het beste? met 34TB zitten we voorlopig wel even goed. Echter moet ik het wel dan als LUN over iscsi gaan mounten en naar mijn idee is EXT4 niet ver genoeg om een disk van 34TB te kunnen maken, of heb ik het mis? 16TB is grootst aangeraden, maar gaat het me tegenwerken? Ik heb de keuze uit ext2 /ext3 / ext4 / reiserfs3

Idera is wat we nodig hebben... block level backup vind je nergens anders, bacula werd super traag met postgresql met +1 biljoen entry's

edit: we gaan trouwens dus voor 2 aparte machines

[ Voor 4% gewijzigd door marco208 op 04-02-2014 11:19 ]

[Q]

Als IOPs de grote bottleneck is, dan zijn mirored vdevs de beste optie (meeste IOPS). Een gulden middenweg tussen storage vs. IOPS is dus door groepjes van 3 disks in RAIDZ1 als vdevs toe te voegen (experimenteer).

Qua file system kun je alleen met XFS voorbij de 16TB grens, als je geen ZFS kunt gebruiken. Ik begrijp echter niet goed waarom je met LUNs en iSCSI aan de slag gaat. Op deze weg verlies je een stukje voordeel dat ZFS je kunt bieden zoals checksums op file-niveau.

Wil je de storage als een lokaal volume presenteren aan de backup software? Waarom niet NFS? Kun je op die machine ook niet gewoon met ZFS werken?

[ Voor 14% gewijzigd door Q op 04-02-2014 16:04 ]

[marco208]

Nee, helaas het programma werkt alleen op Linux niet op Solaris... ZFS op centos werd door jullie afgeraden dus zfs machine (openindiana goed?) met iscsi naar centos toe. XFS kan ook al niet, ze zijn strikt in wat kan en niet...

[Q]

Ik was in de veronderstelling dat het om Linux ging. ZoL werkt prima op Debian en Ubuntu en CentOS is ook gewoon supported door ZoL? http://zfsonlinux.org/epel.html Ik ben even de draad kwijt denk ik.

[ Voor 9% gewijzigd door Q op 04-02-2014 20:19 ]

[raymondw]

Vind het wel frappant dat er verschillende EXT standaarden staan en ReiserFS, maar dat XFS niet mag.
Op CentOS zou ik niet verder gaan dan de standaard melding van 16TB, daarboven kies ik altijd voor XFS.
(Geen optie, dat snap ik)

Nu is de storage voor mij meestal geen probleem, dit is mijn setup voor werkgerelateerde projecten:
8x 2 of 4 TB disken in RAID5 of 6
Deze blokken verdeel ik meestal over meerdere controllers
Dat word dat in CentOS gekoppeld in een RAID0
XFS tuning aanpassen aan wensen en config van de controllers.
Sweatspot size/perf is dan zo rond de 900TB/1PB per setje.

Paar 10Gb interfaces erboven en klaar ben je.
Voor mij een gegarandeerde setup qua stabiliteit en performance.

Zie zelf geen heil in ZFS ivm de ondersteuning cq support.
(Mijn enige referentie had een verloren systeem na een powerfailure)

Misschien dat een goeie XFS referentie je leven een stuk vriendelijker kan maken...

[Q]

@raymondw: Dat zijn pittige grote setups (wow), hoe monitor je de integriteit van je data?

[ Voor 6% gewijzigd door Q op 05-02-2014 08:21 ]

[ppl]

Q schreef op dinsdag 04 februari 2014 @ 20:18:
Ik was in de veronderstelling dat het om Linux ging. ZoL werkt prima op Debian en Ubuntu en CentOS is ook gewoon supported door ZoL? http://zfsonlinux.org/epel.html Ik ben even de draad kwijt denk ik.

Linux != Linux. Er zitten nogal wat cruciale verschillen in Linux distro's waardoor je niet zomaar een totaal andere distro kunt gebruiken. Iets wat op CentOS draait zomaar even op Ubuntu of Debian gaan draaien kan dus niet altijd. Daarnaast is ZoL ook niet bij iedere distro even goed geïmplementeerd zoals zovele andere technologieën (wat dacht je van iets als Xen? om maar eens iets anders te noemen). Afgezien daarvan zijn de ervaringen met ZoL ook lang niet allemaal denderend en doet het op een OpenSolaris afgeleide of iets als FreeBSD het nog altijd een stuk beter (komt o.a. doordat ze daar wat verder voorop lopen).

raymondw schreef op dinsdag 04 februari 2014 @ 22:42:
Vind het wel frappant dat er verschillende EXT standaarden staan en ReiserFS, maar dat XFS niet mag.

Ext2, 3 en 4 zijn met elkaar compatible en zijn bij veruit de meeste distro's de default. ReiserFS wordt nog enigszins gebruikt in de Red Hat wereld. XFS is wat minder bekend. Met andere woorden, er wordt hier gekeken naar hoe de support van de verschillende filesystems is. Dan is het helemaal niet frappant, raar, merkwaardig, enz. dat je bij ext2, 3, 4 en ReiserFS uitkomt.

Zie zelf geen heil in ZFS ivm de ondersteuning cq support.
(Mijn enige referentie had een verloren systeem na een powerfailure)

En zo hebben ze hier misschien wel die ervaring met XFS of weet ik welk ander filesystem dan ook. Je kunt met je eigen redenatie jouw terughoudendheid omtrent ZFS net zo hard afschieten Het wordt immers op grote schaal door verschillende bekende namen toegepast in allerlei scenario's. Zat bedrijven die support doen en waar je zelfs complete appliances kunt kopen met allerlei support contracten erop. Nexenta is 1 van de bekendere namen hier in.

[Q]

ppl schreef op donderdag 06 februari 2014 @ 21:09:
[...]

Linux != Linux. Er zitten nogal wat cruciale verschillen in Linux distro's waardoor je niet zomaar een totaal andere distro kunt gebruiken. Iets wat op CentOS draait zomaar even op Ubuntu of Debian gaan draaien kan dus niet altijd. Daarnaast is ZoL ook niet bij iedere distro even goed geïmplementeerd zoals zovele andere technologieën (wat dacht je van iets als Xen? om maar eens iets anders te noemen). Afgezien daarvan zijn de ervaringen met ZoL ook lang niet allemaal denderend en doet het op een OpenSolaris afgeleide of iets als FreeBSD het nog altijd een stuk beter (komt o.a. doordat ze daar wat verder voorop lopen).

Mijn ervaring is anders ZoL werkt uitstekend dus ik vraag me dan af wat er precies niet zo denderend is.