Mac Pro + ZFS fibre channel SAN build

[Femme]

Ik heb besloten om mijn Windows-workstation eindelijk eens de deur uit te trappen en te vervangen door een Mac Pro. Ik ben een liefhebber van snelle storage en heb in het verleden altijd redelijk dikke raidconfiguraties gebruikt. In de afgelopen jaren is er nogal wat gebeurd op dit gebied. Ik wil het dit keer anders aanpakken dat met dikke raidcontrollers en hoogtoerige harde schijven.

De huidige situatie is dat ik een Windows-workstation heb met de volgende specs:

- Core i7 930
- 12GB RAM
- Areca ARC-1280
- 4x Mtron Mobi 3000 16GB in raid 0 voor boot
- 5x OCZ Vertex 30GB in raid 5 voor data
- 6x Western Digital Velociraptor 300GB in raid 5 voor data (foto's en video)
- Totaal datagebruik ca. 1TB

Verder heb ik nog een Windows 7-server met de volgende specs:

- Atom 330
- 4GB RAM
- Areca ARC-1280
- 4x Western Digital WD20EARS 2TB in raid 5
- 4x Seagate Barracuda LP 1,5TB in raid 5
- 4x Western Digital Caviar RE2 500GB in raid 5
- Chenbro-behuizing met twaalf 3,5 inch hotswap bays
- Unieke datagebruik ca. 1,7TB en 2x backup van al mijn data (van server en workstation)

De bovenstaande hardware staat ergens in het oosten van het land. Sinds een half jaar overnacht ik in Utrecht op de dagen dat ik op ons kantoor werk in Amsterdam. 's Avonds maak ik dan gebruik van een MacBook Air. Momenteel kan ik op die dagen niet bij mijn data tenzij ik het vooraf gekopieerd heb. Het zou handig zijn al ik altijd bij mijn data kan.

De prestaties van de file shares op de server zijn erg ruk. Ik haal hooguit 40MB/s bij het maken van backups (maar vaak veel minder) terwijl er aan beide kanten opslag met dikke raid-arrays wordt gebruikt. De scheduling van de Areca zorgt er regelmatig voor dat reads lang uitgesteld worden als er veel writes op een array plaatsvinden. Dit is nogal irritant. Ik heb een tijdje Ubuntu gedraaid op de server maar dat presteerde nog slechter dan Windows. Ik heb dus een hoop dure en dubbele hardware (in workstation en server) die maar matig presteert. Ik heb liever een eenvoudiger opstelling waarin de opslag is gecentraliseerd in een SAN en slimme caching ervoor zorgt dat ik met goedkope laagtoerige harde schijven en simpele sata-controllers uitkan. Dat zou mogelijk moeten zijn met ZFS.

Wat betreft prestaties wil ik iets dat vergelijkbaar is met direct attached storage. Ik wil een pijp van zeker 400MB/s tussen de Mac Pro en de storage server en opslag met lage latencies. De beste oplossingen hiervoor lijken fibre channel over iSCSI over 10Gb ethernet. In beide gevallen wil ik point-to-point verbindingen gebruiken zodat ik geen dure switches nodig heb. 10GbE kost zo'n 350 euro per adapter. Dual channel 4Gb fibre channel is wat duurder dan 10GbE maar heeft niet de overhead van iSCSI. Ik heb alleen geen flauw idee of 'link aggregation' of hoe het ook heet bij FC gaat werken met p2p-verbindingen van twee poorten? Op dit moment heb ik nog de ballen verstand van fibre channel, ZFS en OpenSolaris maar ik begreep dat je een ZFS-volume met behulp van Comstar toegankelijk kunt maken als een fibre channel of iSCSI LUN. Het zou handig zijn als beide mogelijk is zodat ik hetzelfde volume kan mounten op de MacBook Air via een software iSCSI-initiator. Het zou helemaal leuk zijn als dit mogelijk is vanaf elke plek op de wereld waar een internetverbinding beschikbaar is.

De Mac Pro is een 2,8GHz quad-core basisconfiguratie die ik wil voldouwen met RAM en verder kaal wil houden. Voor zover ik begrepen heb is het met de dual 4Gb fibre channel adapter van Apple mogelijk om te booten vanaf een FC LUN. Dit zou leuk zijn want dan heb ik geen boot-ssd nodig in de Mac Pro.
Voor de server denk ik aan een Core i5-mobo met 16GB RAM en zes sata-poorten. De Areca ARC-1280 gaat eruit vanwege zijn hoge energieverbruik (20-25 watt). Ik heb nog een ARC-1680 liggen waarop ik de harde schijven in pass-through modus zou kunnen gebruiken. Ik kom dan in totaal op 14 poorten. Hier wil ik acht 2TB harde schijven op aansluiten verdeeld over twee raid-z pools, één voor de primaire data en de andere voor backups. De vijf Vertexen (in totaal 150GB) zou ik als L2ARC kunnen gebruiken. Voor de ZIL heb ik eventueel dan nog een veiliger ssd nodig met een supercapacitor.

Vragen die ik zoal heb:

- Welk besturingsssysteem? OpenSolaris?
- Hoe gaat fibre channel link aggregation in zijn werk bij een p2p-verbinding?
- Kan ik hetzelfde volume toegankelijk maken via FC en iSCSI? (voor de duidelijkheid: gelijktijdig gebruik is niet van toepassing)
- Kan ik prestaties verwachten die vergelijkbaar zijn met die van direct attached storage in raid?
- Wat doe ik met de boot-drive in de server? Kan booten vanaf de ssd's die ook in de L2ARC worden gebruikt of kan ik beter aparte drives gebruiken (kost sata-poorten)

[Anoniem: 15758]

Ah ons eigen Femme!

Femme schreef op zondag 24 juli 2011 @ 14:34:
Ik heb besloten om mijn Windows-workstation eindelijk eens de deur uit te trappen

Ik ben een liefhebber van snelle storage en heb in het verleden altijd redelijk dikke raidconfiguraties gebruikt. In de afgelopen jaren is er nogal wat gebeurd op dit gebied. Ik wil het dit keer anders aanpakken dat met dikke raidcontrollers en hoogtoerige harde schijven.

Groot gelijk heb je.

De scheduling van de Areca zorgt er regelmatig voor dat reads lang uitgesteld worden als er veel writes op een array plaatsvinden. Dit is nogal irritant.

Ken ik ja, alle reads blokkeren gewoon en dat merk je zeker. Echter, ZFS doet ongeveer vergelijkbare dingen met transaction groups; wat ook voor blokkerende reads kan zorgen. Dat probleem komt vaak door te weinig geheugen waardoor ZFS niet tegelijkertijd de transactie group kan wegschrijven en nieuwe data kan accepteren, en valt zelfs met weinig RAM te tweaken. Maar in principe heeft ZFS op dit punt wel een klein nadeel. Het offert niets op voor veilige, betrouwbare storage. Daar valt prima om heen te werken; met gebruik van moderne ZFS versies, SSDs voor L2ARC en vooral SLOG, de juiste tweaks/settings en genoeg RAM. Maar in een slechte setup kun je dus hetzelfde probleem krijgen; ik waarschuw maar vast.

Ik heb liever een eenvoudiger opstelling waarin de opslag is gecentraliseerd in een SAN en slimme caching ervoor zorgt dat ik met goedkope laagtoerige harde schijven en simpele sata-controllers uitkan. Dat zou mogelijk moeten zijn met ZFS.

Dat laatste zeker. Met wat bedoel je precies met een SAN? Bedoel je dan iSCSI images? Dan is je storage wel centraal opgeslagen, maar niet centraal toegankelijk. Alleen met een NAS-protocol zoals SMB/CIFS of NFS kunnen meerdere systemen op de centrale storage tegelijk werken. Beide zijn mogelijk bij ZFS, maar het is goed vooraf te bedenken wat voor setup je precies wilt.

Wat betreft prestaties wil ik iets dat vergelijkbaar is met direct attached storage. Ik wil een pijp van zeker 400MB/s tussen de Mac Pro en de storage server en opslag met lage latencies.

Zoiets hoopte ik te bereiken met 10GBaseT. Ik heb onlangs de AT2 adapter in de pricewatch gesubmit en die staat er nu; maar andere 10GbE alternatieven bieden wellicht meer waar voor je geld; maar zijn dan weer incompatible met het populaire BaseT kopernetwerk.

In beide gevallen wil ik point-to-point verbindingen gebruiken zodat ik geen dure switches nodig heb.

Zoiets dacht ik ook; veel adapters zijn dual-port; dan kun je één poort gebruiken voor point-to-point en de ander naar een gigabit switch zodat de rest er ook mee kan communiceren. Dan heb je geen twee aparte NICs nodig; alhoewel dat ook zou kunnen met onboard gigabit opzich.

Op dit moment heb ik nog de ballen verstand van fibre channel, ZFS en OpenSolaris maar ik begreep dat je een ZFS-volume met behulp van Comstar toegankelijk kunt maken als een fibre channel of iSCSI LUN. Het zou handig zijn als beide mogelijk is zodat ik hetzelfde volume kan mounten op de MacBook Air via een software iSCSI-initiator. Het zou helemaal leuk zijn als dit mogelijk is vanaf elke plek op de wereld waar een internetverbinding beschikbaar is.

Hmm. Hou in je achterhoofd dat iSCSI dus een SAN-protocol is: de client bestuurt het filesystem. Je zet dan bijvoorbeeld een HFS (mac) of NTFS (windows) filesystem op een logisch volume dat via iSCSI naar je server gaat en via een 'ZVOL' op ZFS wordt gezet. Dat zijn véél lagen die ertussen liggen en voor high-performance I/O lijkt me dat niet erg wenselijk. Wellicht kun je je beter focussen op SMB/CIFS of NFS toegang, in plaats van iSCSI?

De Mac Pro is een 2,8GHz quad-core basisconfiguratie die ik wil voldouwen met RAM en verder kaal wil houden. Voor zover ik begrepen heb is het met de dual 4Gb fibre channel adapter van Apple mogelijk om te booten vanaf een FC LUN. Dit zou leuk zijn want dan heb ik geen boot-ssd nodig in de Mac Pro.

Ja dat zou denk ik wel kunnen. Ik heb geen ervaring met macs maar ik heb wel een bootable Ubuntu + ZFS ZVOL + iSCSI werkend gekregen. Vereist wel enige setup en geduld; maar dan heb je ook wat.

Voor de server denk ik aan een Core i5-mobo met 16GB RAM en zes sata-poorten. De Areca ARC-1280 gaat eruit vanwege zijn hoge energieverbruik (20-25 watt). Ik heb nog een ARC-1680 liggen waarop ik de harde schijven in pass-through modus zou kunnen gebruiken. Ik kom dan in totaal op 14 poorten. Hier wil ik acht 2TB harde schijven op aansluiten verdeeld over twee raid-z pools, één voor de primaire data en de andere voor backups. De vijf Vertexen (in totaal 150GB) zou ik als L2ARC kunnen gebruiken. Voor de ZIL heb ik eventueel dan nog een veiliger ssd nodig met een supercapacitor.

Dit is geen slechte config, maar je kunt overwegen het net iets anders te doen:

• Bulldozer 8-core of interlagos ('server bulldozer') 16-core setup
• 32 gigabyte (8x 4GiB) 1.25V low voltage DDR3 DRAM (eventueel ECC alhoewel ik de combinatie 1.25V en non-registered ECC DRAM nog niet heb gevonden)
• Onboard 6 SATA/600 poorten voor SSDs
• Add-on controller(s) voor hardeschijven. Bijvoorbeeld SuperMicro USAS2-L8e.

Die Areca 1680 controller ken ik niet zo goed. Maakt die gebruik van (interne) SAS expanders? ZFS doet alle I/O op alle members dus dedicated bandwidth voor elke schijf is sterk aan te bevelen. Ook kunnen RAID-achtige controllers je schijven eruit kicken bij bad sectors of andere timeouts. Dit heb ik zelf ervaren met mijn Areca ARC-1220 controller. Ook heb je door de RAID SOC extra latencies wat ik zelf heb gemeten op 0.1ms verschil ten opzichte van de onboard chipset SATA poorten. Voor ZFS is dit niet de beste setup; alhoewel het natuurlijk een overweging is om bestaande hardware te hergebruiken.

ZFS heeft eigenlijk niet zo sterke hardware nodig, het probleem is dat ZFS juist hele andere hardware nodig heeft dan gangbare systemen. De honger naar meer geheugen is extreem. Voor een high-performance setup moet je dus vooral op dit punt niet bezuinigen. Met te weinig geheugen vallen de disks stil en dat kost je performance.

Dat interlagos is maar een ideetje; ik weet niet wanneer die uitkomt. Maar Bulldozer of Interlagos zou opzich een mooi high-end ZFS setup zijn; laag idle verbruik omdat AMD nu net als Intel een High-K Metal Gate procédé gebruikt om lekstroom te minimaliseren. Dat is te zien met extreem lage Llano idle power consumption bijvoorbeeld. Alleen Llano zijn nog ouderwetse Phenom cores; Bulldozer is de nieuwe chip van AMD en grofweg 50% sneller; best significant. Ook die 8 cores is iets wat ZFS helemaal kan gebruiken; zeker als je compressie, encryptie of andere dingen zoals de-dupe wilt gaan gebruiken. 8 cores is eigenlijk wel genoeg, maar interlagos heeft quad channel DRAM en dat kan betekenen lekker goedkoop veel DDR3 geheugen wegstouwen en ook meer geheugenbandbreedte iets wat voor jouw performancetarget ook welkom zou zijn.

Bovenstaande adviezen zijn misschien iets over de top; maar als je voor high performance gaat en dure netwerkadapters gaat kopen, kun je maar beter zorgen dat ZFS de datarate goed kan bijhouden.

- Welk besturingsssysteem? OpenSolaris?

Ik ben zelf erg bekend met FreeBSD, daarop is ZFS wel iets langzamer met 4GiB RAM en lager t.o.v. Solaris platform; maar daarboven kun je uitstekende snelheden halen. FreeBSD heeft minder beperkingen dan Solaris en ook betere hardware support. Solaris is wel de thuisbasis van ZFS en er zijn aardig wat projecten waar je uit kunt kiezen. OpenSolaris+napp-it is een veelgenoemde optie. Maar ik zou een kale FreeBSD setup ook overwegen. Ben je bereid met SSH/shell UNIX te werken, of wil je echt een web-interface?

- Hoe gaat fibre channel link aggregation in zijn werk bij een p2p-verbinding?

Hoop dat iemand anders deze vraag voor je kan beantwoorden.
Wel kan ik melden dag lagg (link aggregation) niet automatisch betekent dat je point-to-point de extra bandbreedte kunt gebruiken. Je moet protocol-violating 'round robin' gebruiken en dan nog heb je het probleem dat één interface meer traffic te verwerken krijgt dan andere interfaces. 70-30% heb ik ooit eens gelezen. Ik zou dit goed uitzoeken als je echt lagg wilt gaan gebruiken. lagg voor redundancy is makkelijk maar voor extra point-to-point bandbreedte (een 20Gbps link ofzo) is omslachtig als het überhaupt al werkend is te krijgen.

- Kan ik hetzelfde volume toegankelijk maken via FC en iSCSI? (voor de duidelijkheid: gelijktijdig gebruik is niet van toepassing)

Now i'm confused! FC = netwerk, iSCSI = protocol/service over het netwerk. Wat bedoel je precies? Of bedoel je van die FibreChannel insteekkaarten die een hardeschijf presenteren en dus hardwarematig iSCSI implementeren? Dat laatste heb ik geen ervaring mee; ik zou het op open source technieken houden.

- Kan ik prestaties verwachten die vergelijkbaar zijn met die van direct attached storage in raid?

Met een goede config; jawel. Maar goed gebruik van SSDs is noodzakelijk of je zult zeker tragere storage hebben dan een DAS. Latencies zijn door het netwerk altijd hoger, maar zelfs over gigabit heb ik 0.2ms random reads gehaald (iSCSI) dus met 10 gigabit zou dat geen groot probleem mogen zijn.

- Wat doe ik met de boot-drive in de server? Kan booten vanaf de ssd's die ook in de L2ARC worden gebruikt of kan ik beter aparte drives gebruiken (kost sata-poorten)

Solaris kan SSDs niet voor meerdere functies gebruiken. Je kunt een SSD dus of voor booten gebruiken, of voor L2ARC, of voor SLOG. FreeBSD kent die beperking niet en je kunt één SSD voor drie of zelfs meer taken gebruiken.

Die vertexen van je kun je voor meerdere dingen gebruiken:

• boot/systeem disk van 20GB ofzo; als ZFS mirror op 4+ disks
• raid0 van alle SSDs als primary storage (dus ZFS pool) bijvoorbeeld voor VMs die veel random I/O te verwerken krijgen
• raid0 van alle SSDs in L2ARC

Dan zit je nog met SLOG. Je kunt echt maar beter een veilige SSD hiervoor gebruiken. Dus een Intel 320 met firmware fix is een goede keuze; de 120GB kent een redelijke writesnelheid.

Echter, er is nog een andere - duurdere - high-end optie en dat is de nieuwe Intel 720 series PCI-express SSD die 2GB/s echte performance kan halen; nog weinig details bekend maar dit zou een monsterlijk beest moeten zijn wat uitermate geschikt zou zijn voor ZFS. Zie voor specs:
http://www.slashgear.com/...-specs-revealed-16159666/

Voorlopig even genoeg leesvoer; en sommige adviezen/suggesties hierboven zijn een radicale draaiing van je originele plan in het bijzonder wat betreft hergebruik van (dure) onderdelen die je al hebt. Maar daar moet je zelf maar een afweging in maken; als je echt high-end wilt gaan zijn er betere keuzes zoals die 720 series SSD en een andere systeemconfiguratie.

Voel je vrij meer vragen te stellen; ik help onze storage-koning natuurlijk graag.

[DJ-Visto]

Leuk topic Netwerk > 1 gbit/s ervaringen topic

Goedkope 10Gb netwerkkaartjes: http://cgi.ebay.com/2-Top...ain_0&hash=item5ae1b0062d

Leesvoer http://davidhunt.ie/wp/?p=232

En er stana ook nog 2 infiniband kaartjes te koop in de V&A

[ruitech]

En er stana ook nog 2 infiniband kaartjes te koop in de V&A

Stonden :-)
Maar is wel een hele leuke snelle (goedkopere) oplossing. Ben alleen onbekend met de ondersteuning onder Mac OS

[Pixeltje]

ruitech schreef op maandag 25 juli 2011 @ 20:55:
[...]

Stonden :-)
Maar is wel een hele leuke snelle (goedkopere) oplossing. Ben alleen onbekend met de ondersteuning onder Mac OS

Ik dacht dat Infiniband en mac niet zo goed deden kletsen met elkaar. Waarschijnlijk gewoon omdat er geen/weinig support voor is.

Femme, Ik ben onlangs bezig geweest met inlezen en prutsen over en aan NFS, denk dat het makkelijker en sneller is om NFS toegang te regelen in plaats van iSCSI. Wat CiPHER zegt is waar; de lagen die je nodig hebt om van hfs (+) naar zfs te komen zorgen voor performance degradatie. Dit kun je ten dele ondervangen door een beest van een pc neer te zetten, maar die kost heel-veel-geld en is waarschijnlijk niet echt energiezuinig. Nog afgezien van het feit dat je niet alle "vertraging" kunt wegnemen.

NFS wordt in principe vanaf de host-side als een intern volume beschouwd en dus zou je, als je een rappe verbinding met je storage hebt, erg vlot moeten kunnen communiceren met je data

[Femme]

Anoniem: 15758 schreef op maandag 25 juli 2011 @ 10:49:

Dat laatste zeker. Met wat bedoel je precies met een SAN? Bedoel je dan iSCSI images? Dan is je storage wel centraal opgeslagen, maar niet centraal toegankelijk. Alleen met een NAS-protocol zoals SMB/CIFS of NFS kunnen meerdere systemen op de centrale storage tegelijk werken. Beide zijn mogelijk bij ZFS, maar het is goed vooraf te bedenken wat voor setup je precies wilt.

[...] Hmm. Hou in je achterhoofd dat iSCSI dus een SAN-protocol is: de client bestuurt het filesystem. Je zet dan bijvoorbeeld een HFS (mac) of NTFS (windows) filesystem op een logisch volume dat via iSCSI naar je server gaat en via een 'ZVOL' op ZFS wordt gezet. Dat zijn véél lagen die ertussen liggen en voor high-performance I/O lijkt me dat niet erg wenselijk. Wellicht kun je je beter focussen op SMB/CIFS of NFS toegang, in plaats van iSCSI?

Een gedeelte van de storage op de server zal via NFS of SMB file sharing toegankelijk moeten zijn maar de opslag die ik in de Mac Pro nodig heb hoeft alleen maar voor deze machine toegankelijk te zijn en wil ik liever mounten als een block level device (en zou idealiter ook gemount moeten kunnen worden op de MBA als de Mac Pro uit staat).

Mijn ervaring met file sharing onder Windows en SMB in Linux is dat het compleet ruk presteert op gigabit ethernet. Ik mag een gat in de lucht springen als ik eens een piek bereik van 70MB/s maar meestal gaat er niet meer dan 25-40MB/s over het lijntje. Dit terwijl ik verhalen lees dat iSCSI over gigabit wel snelheden haalt die ongeveer gelijk staan aan de bandbreedte van de interface.

Die Areca 1680 controller ken ik niet zo goed. Maakt die gebruik van (interne) SAS expanders? ZFS doet alle I/O op alle members dus dedicated bandwidth voor elke schijf is sterk aan te bevelen. Ook kunnen RAID-achtige controllers je schijven eruit kicken bij bad sectors of andere timeouts. Dit heb ik zelf ervaren met mijn Areca ARC-1220 controller. Ook heb je door de RAID SOC extra latencies wat ik zelf heb gemeten op 0.1ms verschil ten opzichte van de onboard chipset SATA poorten. Voor ZFS is dit niet de beste setup; alhoewel het natuurlijk een overweging is om bestaande hardware te hergebruiken.

De reden om de ARC-1680 te gebruiken is dat ik deze nog heb liggen. Ik zou ook een single socket serverbordje met onboard sas kunnen halen. Die heeft ook 14 poorten. Dit zal ook wat energiezuiniger zijn.

Dat interlagos is maar een ideetje; ik weet niet wanneer die uitkomt. Maar Bulldozer of Interlagos zou opzich een mooi high-end ZFS setup zijn; laag idle verbruik omdat AMD nu net als Intel een High-K Metal Gate procédé gebruikt om lekstroom te minimaliseren. Dat is te zien met extreem lage Llano idle power consumption bijvoorbeeld. Alleen Llano zijn nog ouderwetse Phenom cores; Bulldozer is de nieuwe chip van AMD en grofweg 50% sneller; best significant. Ook die 8 cores is iets wat ZFS helemaal kan gebruiken; zeker als je compressie, encryptie of andere dingen zoals de-dupe wilt gaan gebruiken. 8 cores is eigenlijk wel genoeg, maar interlagos heeft quad channel DRAM en dat kan betekenen lekker goedkoop veel DDR3 geheugen wegstouwen en ook meer geheugenbandbreedte iets wat voor jouw performancetarget ook welkom zou zijn.

Bovenstaande adviezen zijn misschien iets over de top; maar als je voor high performance gaat en dure netwerkadapters gaat kopen, kun je maar beter zorgen dat ZFS de datarate goed kan bijhouden.

Ik heb er niet direct haast bij om het systeem te bouwen dus ik zou kunnen wachten op Bulldozer. Geheugen is erg goedkoop tegenwoordig dus 32GB RAM moet ook wel kunnen.

Ik ben zelf erg bekend met FreeBSD, daarop is ZFS wel iets langzamer met 4GiB RAM en lager t.o.v. Solaris platform; maar daarboven kun je uitstekende snelheden halen. FreeBSD heeft minder beperkingen dan Solaris en ook betere hardware support. Solaris is wel de thuisbasis van ZFS en er zijn aardig wat projecten waar je uit kunt kiezen. OpenSolaris+napp-it is een veelgenoemde optie. Maar ik zou een kale FreeBSD setup ook overwegen. Ben je bereid met SSH/shell UNIX te werken, of wil je echt een web-interface?

Als ik gewoon via de command-line fatsoenlijk inzicht kan krijgen hoe m'n opslag is geconfigureerd vind ik het prima om via de command-line te werken.

Hoop dat iemand anders deze vraag voor je kan beantwoorden.
Wel kan ik melden dag lagg (link aggregation) niet automatisch betekent dat je point-to-point de extra bandbreedte kunt gebruiken. Je moet protocol-violating 'round robin' gebruiken en dan nog heb je het probleem dat één interface meer traffic te verwerken krijgt dan andere interfaces. 70-30% heb ik ooit eens gelezen. Ik zou dit goed uitzoeken als je echt lagg wilt gaan gebruiken. lagg voor redundancy is makkelijk maar voor extra point-to-point bandbreedte (een 20Gbps link ofzo) is omslachtig als het überhaupt al werkend is te krijgen.

Bij sas werkt 'link aggregation' (een wide port) automatisch. Als je een kabel met vier links van het ene device in het andere sas-device stopt zetten ze automatisch een wide port op. Ik vind echter nergens terug hoe dit bij FC werkt.

Now i'm confused! FC = netwerk, iSCSI = protocol/service over het netwerk. Wat bedoel je precies? Of bedoel je van die FibreChannel insteekkaarten die een hardeschijf presenteren en dus hardwarematig iSCSI implementeren? Dat laatste heb ik geen ervaring mee; ik zou het op open source technieken houden.

Met Comstar in OpenSolaris kan ik een fibre channel of iSCSI storage array maken met onderliggend een ZFS-volume (of hoe je dat ook noemt) als opslag. Ik vraag me alleen af of dat ook beide tegelijkertijd mogelijk is (zelfde volume exposen via FC én iSCSI over ethernet) zou ik zou kunnen mounten via FC op de Mac Pro of (als het volume niet is gemound op de Mac Pro) iSCSI over ethernet op de MacBook Air.

Met een goede config; jawel. Maar goed gebruik van SSDs is noodzakelijk of je zult zeker tragere storage hebben dan een DAS. Latencies zijn door het netwerk altijd hoger, maar zelfs over gigabit heb ik 0.2ms random reads gehaald (iSCSI) dus met 10 gigabit zou dat geen groot probleem mogen zijn.

Ik ga waarschijnlijk voor FC omdat het goedkoper is en het lijkt me ook er minder overhead is dan met iSCSI over ethernet. Ik wil sowieso ssd's gaan gebruiken. Ik heb ook nog een Vertex 120GB die ik in de L2ARC zou kunnen stoppen.

Solaris kan SSDs niet voor meerdere functies gebruiken. Je kunt een SSD dus of voor booten gebruiken, of voor L2ARC, of voor SLOG. FreeBSD kent die beperking niet en je kunt één SSD voor drie of zelfs meer taken gebruiken.

Die vertexen van je kun je voor meerdere dingen gebruiken:

• boot/systeem disk van 20GB ofzo; als ZFS mirror op 4+ disks
• raid0 van alle SSDs als primary storage (dus ZFS pool) bijvoorbeeld voor VMs die veel random I/O te verwerken krijgen
• raid0 van alle SSDs in L2ARC

Dan zit je nog met SLOG. Je kunt echt maar beter een veilige SSD hiervoor gebruiken. Dus een Intel 320 met firmware fix is een goede keuze; de 120GB kent een redelijke writesnelheid.

Wellicht kan ik beter kijken naar een 16-poorts sas-controller (of een extra 8-poorts controller naast een onboard controller) voor erbij. Ik heb twaalf 3,5 inch drive bays en 10 ssd's liggen die ik zou kunnen gebruiken. De Mtron 16GB drives zijn in principe prima te gebruiken voor boot.

Voel je vrij meer vragen te stellen; ik help onze storage-koning natuurlijk graag.

Thanks voor je hulp so far

Pixeltje schreef op maandag 25 juli 2011 @ 21:10:
[...]

Ik dacht dat Infiniband en mac niet zo goed deden kletsen met elkaar. Waarschijnlijk gewoon omdat er geen/weinig support voor is.

Ik heb ook naar Infiniband zitten kijken maar ik kan geen Infiniband-adapters vinden met ondersteuning voor OS X. Er draaien wel hpc-clusters van Macs met Infiniband. Gee idee welke adapters daarvoor zijn gebruikt.

[Pixeltje]

Hmm, even gezocht en dit is wat ik vond;

Uit 2004 al, maar zou dus betekenen dat het er inmiddels wel moet zijn Lijkt me alleen wat merkspecifiek.

En dit is het vervolg neem ik aan.

Ook een oud artikel, maar hier hebben ze het over Mellanox.

En er is een adapter, (ook in "mac edition") van Highpoint.. de 'RocketRAID 2224 SATA PCI-X host adapter with Infiniband port' Hier wat benches zo te zien.

[phoenix]

Wat is de reden dat je een Mac Pro kiest? Ik lees dat je er over denkt om OpenSolaris erop te zetten. Ik zou zeker checken of dat allemaal compatible is. Ik heb slechte ervaring met Ubuntu op mijn MacBook (OK, dat was dan twee jaar geleden) en weet dat de hardware support van OpenSolaris slechter is.

Het is jammer dat Apple zelf gestopt is met ZFS...

Wat betreft de keus voor operating system: alhoewel ZFS in Solaris is begonnen is het sinds Oracle niet meer zeker wat er mee gaat gebeuren. Ik zou mijn geld zetten op FreeBSD.

[Femme]

Pixeltje schreef op dinsdag 26 juli 2011 @ 13:29:

En er is een adapter, (ook in "mac edition") van Highpoint.. de 'RocketRAID 2224 SATA PCI-X host adapter with Infiniband port' Hier wat benches zo te zien.

Die HighPoint-adapter gebruikt een Infiniband-connector maar er gaat gewoon sata overheen. Er zit geen Infiniband-interface op.

phoenix schreef op dinsdag 26 juli 2011 @ 20:18:
Wat is de reden dat je een Mac Pro kiest? Ik lees dat je er over denkt om OpenSolaris erop te zetten. Ik zou zeker checken of dat allemaal compatible is. Ik heb slechte ervaring met Ubuntu op mijn MacBook (OK, dat was dan twee jaar geleden) en weet dat de hardware support van OpenSolaris slechter is.

Het is jammer dat Apple zelf gestopt is met ZFS...

Wat betreft de keus voor operating system: alhoewel ZFS in Solaris is begonnen is het sinds Oracle niet meer zeker wat er mee gaat gebeuren. Ik zou mijn geld zetten op FreeBSD.

De Mac Pro gaat gewoon OS X draaien, maar zonder lokale storage of alleen met een ssd voor boot. De storage komt in een server die OpenSolaris of een ander besturingssysteem met ondersteuning voor ZFS zal draaien. Doel van de exercitie: alle storage consolideren en een beetje tweaken.

[wagenveld]

Zou dit niet wat zijn:
http://www.anandtech.com/...r6-mac-thunderbolt-review

[Femme]

Ik wil iets hebben waarmee ik een stel ssd's als cache kan inzetten voor een groter array van laagtoerige harde schijven zodat het geheel goed presteert ondanks goedkope harde schijven.

Ik was wat aan het eBay'en en kwam een quad port 4Gb fibre channel adapter tegen voor slechts 275 dollar dus daar heb ik er maar meteen twee van gescoord. Het is een QLogic QLE2464 en hij heeft drivers voor MacOS X en Solaris en ondersteuning voor scsi initiator en target modi dus hij zou ook in de storage server gebruikt moeten kunnen worden als scsi target. Apple's eigen quad port adapter lijkt er verdacht veel op. 4x 4Gb/s is zo'n 1,6GB/s aan bandbreedte, is dat in ieder geval niet de bottleneck .

[Anoniem: 15758]

Femme schreef op dinsdag 26 juli 2011 @ 11:50:
Een gedeelte van de storage op de server zal via NFS of SMB file sharing toegankelijk moeten zijn maar de opslag die ik in de Mac Pro nodig heb hoeft alleen maar voor deze machine toegankelijk te zijn en wil ik liever mounten als een block level device (en zou idealiter ook gemount moeten kunnen worden op de MBA als de Mac Pro uit staat).

Oke, maar wees je bewust van de nadelen van block-level storage zoals via iSCSI. Dan mis je dus bepaalde voordelen van het ZFS filesystem. Je mist file-based checksumming en bescherming tegen filesystem corruptie. ZFS kan dan wel consistent zijn, maar je Mac gebruikt dan gewoon HFS op de block-level storage dus daar kan nog steeds dingen mee misgaan. Je kunt niet sommige directories comprimmeren en andere niet, je kunt niet sommige folders copies=2 meegeven, enzovoorts. Voor ZFS is al je storage dan één grote file of volume (ZVOL). Je mist dus een deel van de unieke ZFS features. Ook heb je extra perforamnce overhead; je client filesystem stuurt flush commando's en moet consistent blijven; en je ZFS filesystem moet ook consistent blijven. Met zo'n setup zul je sterk moeten vertrouwen op een goede SLOG device; anders zal het enorm traag worden! Je kunt onder moderne ZFS wel de 'sync' optie op disabled zetten, maar dan loop je het risico je client filesystem te corrumperen, en dat moet je dus niet doen.

Mijn ervaring met file sharing onder Windows en SMB in Linux is dat het compleet ruk presteert op gigabit ethernet. Ik mag een gat in de lucht springen als ik eens een piek bereik van 70MB/s maar meestal gaat er niet meer dan 25-40MB/s over het lijntje. Dit terwijl ik verhalen lees dat iSCSI over gigabit wel snelheden haalt die ongeveer gelijk staan aan de bandbreedte van de interface.

Mijn ervaringen zijn anders. In het verleden heb ik inderdaad brakke Samba performance, en NFS kan ook problemen krijgen doordat remote locking gebruikt wordt. Maar beide problemen zijn relatief gemakkelijk op te lossen. Moderne Samba releases ondersteunen nu asynchronous I/O dus een soort NCQ voor SMB/CIFS-shares; dat scheelt enorm qua snelheid. Ik krijg nu gewoon 100-110MB/s read performance over gigabit; tegen de theoretische max aan dus.

Als ik gewoon via de command-line fatsoenlijk inzicht kan krijgen hoe m'n opslag is geconfigureerd vind ik het prima om via de command-line te werken.

ZFS werkt erg makkelijk met commando's dus dat gaat wel lukken denk ik. In het begin misschien wat onwennig, na een tijdje weet je je weg vast wel te vinden.

Met Comstar in OpenSolaris kan ik een fibre channel of iSCSI storage array maken met onderliggend een ZFS-volume (of hoe je dat ook noemt) als opslag. Ik vraag me alleen af of dat ook beide tegelijkertijd mogelijk is (zelfde volume exposen via FC én iSCSI over ethernet) zou ik zou kunnen mounten via FC op de Mac Pro of (als het volume niet is gemound op de Mac Pro) iSCSI over ethernet op de MacBook Air.

Dat zou moeten kunnen lijkt me. Zo lang je maar een software iSCSI-target gebruikt (istgt onder FreeBSD). Dan kun je die naar een ZVOL wijzen en gebruiken voor zowel je FC en software iSCSI over ethernet. Ik heb echter alleen ervaring met dat laatste.

Wellicht kan ik beter kijken naar een 16-poorts sas-controller (of een extra 8-poorts controller naast een onboard controller) voor erbij.

Ik raad aan om alleen 8-poort adapters te gebruiken omdat die meer bandbreedte per poort hebben. LSI 1068E of SAS2008 (USAS2-L8e) zijn interessante kandidaten. Beide controllers vind je ook onboard op diverse SuperMicro bordjes. Dan begin je dus al met 6+8=14 SATA poorten.

Ik wil sowieso ssd's gaan gebruiken. Ik heb ook nog een Vertex 120GB die ik in de L2ARC zou kunnen stoppen.

Femme schreef op woensdag 27 juli 2011 @ 03:08:
Ik wil iets hebben waarmee ik een stel ssd's als cache kan inzetten voor een groter array van laagtoerige harde schijven zodat het geheel goed presteert ondanks goedkope harde schijven.

De combinatie low-rpm + SSD is één van de core features van ZFS; zo haal je het beste uit beide technieken. Low-rpm HDDs zijn goed in sequential I/O en SSDs voor de random read + random write.

ZFS ondersteunt:

L2ARC (zeg maar een soort level2 SRAM cache als je vergelijkt met CPU->RAM)
Level2 ARC (Adaptive Replacement Cache) is een coole feature die Intel hedendaags naar Windows probeert te krijgen onder de naam SRT (Smart Response Technology). In feite laat je de HDDs grote bestanden lezen en alle kleine bestanden (random reads) worden vanaf de SSDs getrokken. In tegenstelling tot SRT heeft ZFS een groot voordeel: het weet wanneer data corrupt is, dus L2ARC is compleet veilig. Als je SSD corrupte data terug stuurt dan leest ZFS deze alsnog van de HDD en corrigeert de corruptie. Dus L2ARC kun je veilig gebruiken.

Dingen die je moet weten:

• L2ARC slurpt RAM! Afhankelijk van de grootte van de I/O's heb je meerdere gigabytes RAM nodig per 50GB L2ARC ofzoiets. Moet even opzoeken hoe veel precies.
• L2ARC kan prima in RAID0; dat doet ZFS zelf als je meerdere L2ARC devices gebruikt.
• L2ARC devices gaan per pool; heb je meerdere pools dan kun je partities gebruiken om de SSDs meerdere caches te onderhouden.
• L2ARC kan je pool nooit corrupt maken of anderzins in gevaar brengen
• L2ARC heb je vooral veel random read (qd=32) nodig; alle SSDs zijn dus geschikt behalve JMicron/Toshiba die geen NCQ ondersteunen. Ook je Mtrons zijn denk ik niet erg geschikt om deze reden.

SLOG (Separate LOG of 'ZFS intent log' (ZIL) device)
Waar L2ARC er is om random reads te versnellen, is een SLOG device er om random writes én sequential writes te versnellen. Dat laatste omdat de metadata van ZFS naar de SLOG wordt geschreven, zodat de hardeschijven pure sequential write kunnen doen en geen random writes tussendoor krijgen die de performance omlaag halen.

• Het is niet zo dat álle writes via de SLOG gaan; alleen 'synchronous writes' gaan via de SLOG. Dat is dus ZFS metadata en sync writes via bijvoorbeeld iSCSI die je client/applicaties dus versturen. Denk bijvoorbeeld aan databases die erg veel flush commando's sturen.
• SLOG betekent dat je normale HDD disks géén ZFS Intent Log (ZIL) meer bevatten; je haalt dus een veiligheidsfeature weg en brengt die onder in een aparte device. Dit is potentiëel gevaarlijk. Vóór ZFS versie 19 is een corrupte ZIL het einde van alle data op een pool. Corrupte of missing ZIL = byebye data. Vanaf versie 19 kun je met dataverlies enkele transaction groups terug draaien en alsnog je pool gebruiken, maar duidelijk is dat je een betrouwbare SLOG wilt hebben.
• Mirroren van SLOG kan maar neemt niet alle risico's weg; corruptie van SSDs kan tegelijktijdig gebeuren bij een stroomfailure. Ik raad aan altijd SSDs met supercapacitors te gebruiken voor SLOG, zoals de Intel 320 SSD.
• Je kunt je SLOG net als L2ARC stripen door meerdere SLOGs toe te voegen
• SLOG devices krijgen random writes en sequential writes; nooit reads. Alleen reads na een stroomfailure.

Je kunt prima meerdere SSDs gebruiken voor zowel SLOG als L2ARC. Dat is mijn favoriete setup. Dus bijvoorbeeld:

SSD1: L2ARC + SLOG voor pool1, L2ARC+SLOG voor pool2
SSD2: L2ARC + SLOG voor pool1, L2ARC+SLOG voor pool2
SSD3: L2ARC + SLOG voor pool1, L2ARC+SLOG voor pool2
SSD4: L2ARC + SLOG voor pool1, L2ARC+SLOG voor pool2

Zo haal je het maximale uit je meerdere SSDs. Merk wel op dat Solaris niet veilig je SSD voor meerdere taken kan gebruiken. Onder Solaris platform zou je dus moeten gebruiken:

SSD1: L2ARC voor pool1
SSD2: L2ARC voor pool2
SSD3: SLOG voor pool1
SSD4: SLOG voor pool2

In deze config is je L2ARC en SLOG dus 4x zo langzaam, omdat je geen (ZFS) striping toepast.

[Q]

Leuke uitdaging!

Letop dat OpenSolaris officieel dood is. OpenIndiana is de community voortzetting er van maar ik zou mijn storage niet aan zo'n klein platform toevertrouwen.

Wikipedia: OpenSolaris

Effectief ga je twee systemen als 1 systeem maken. 1 systeem als computer, 1 systeem als storage. Een goede UPS zou dan wel fijn zijn. Door met 2 systemen te gaan werken heb je 2x zoveel kans op ellende.

Ik heb zelf een tijdje timemachine over iSCSI gedraaid en ik heb een keer mee gemaakt dat ik met een volledig corrupte TM disk zat door netwerk problemen.


Ik weet niet of je de Mac Pro al hebt gekocht, maar zo'n ding is zo duur, waarom niet een iMac? Als je nog even geduld hebt komt er wel een thunderbolt oplossing waarmee je snelle storage aan je mac kunt koppelen. Geldt mogelijk ook voor de mac pro, het is wat je wilt. Prive vind ik zaken als geluidsproductie en een groot scherm ook belangrijk.

Je gaat voor een DAS/SAN achtige oplossing, Maar zou de FC oplossing niet mooi zijn om als basis te gebruiken om IP over te doen en daar dan gewoon SMB of AFP over te draaien? Test het eens, wie weet heb je dan toch snelle storage, maar niet de complexiteit van een SAN oplossing.

Mijn download server is met Linux bonding gekoppeld aan mijn NAS zodat ik onderling 220 MB/s file transfers haal, handig om HD content snel te 'archiveren'. Naar mijn mac heb ik gewoon gigabit, maar ik zou niet weten waarom ik al die storage direct aan mijn computer gekoppeld zou willen hebben? Waarom wil je dat persé?

Het voordeel van een ouderwetse NAS oplossing is dat het heel robuust is en je met twee losstaande systemen werkt. Problemen met een van de twee heeft geen effect op de ander. Continue 2 systemen aan moeten laten staan is ook wel zonde en geluidsproductie?

De mac pro biedt je wel de mogelijkheid om intern wat snelle storage te zetten, boot SSD en nog wat disks voor wat lokale grote storage, als je dat perse wilt.

Ik ben benieuwd waarom je behalve voor de kick zo'n snelle SAN achting oplossing wilt maken. Het is snel maar het lijkt me minder robuust dan een oude vertrouwde NAS oplossing. En dan moet je nog aan FreeBSD als je iets met zfs wilt.
Dat doe je ook niet voor je lol. Linux is triviaal, BSD vereist waarschijnlijk meer tijd en moeite. Het is wat je wilt.

[ Voor 12% gewijzigd door Q op 29-07-2011 09:23 ]

[Femme]

Anoniem: 15758 schreef op woensdag 27 juli 2011 @ 10:58:
[...]

Oke, maar wees je bewust van de nadelen van block-level storage zoals via iSCSI. Dan mis je dus bepaalde voordelen van het ZFS filesystem. Je mist file-based checksumming en bescherming tegen filesystem corruptie. ZFS kan dan wel consistent zijn, maar je Mac gebruikt dan gewoon HFS op de block-level storage dus daar kan nog steeds dingen mee misgaan. Je kunt niet sommige directories comprimmeren en andere niet, je kunt niet sommige folders copies=2 meegeven, enzovoorts. Voor ZFS is al je storage dan één grote file of volume (ZVOL). Je mist dus een deel van de unieke ZFS features. Ook heb je extra perforamnce overhead; je client filesystem stuurt flush commando's en moet consistent blijven; en je ZFS filesystem moet ook consistent blijven. Met zo'n setup zul je sterk moeten vertrouwen op een goede SLOG device; anders zal het enorm traag worden! Je kunt onder moderne ZFS wel de 'sync' optie op disabled zetten, maar dan loop je het risico je client filesystem te corrumperen, en dat moet je dus niet doen.

Daar staat tegenover dat ik met fibre channel op een goedkopere manier (met refurbished enterprise hardware) aan een snelle verbinding tussen client en server kan komen. 10GbE is zo'n 500 euro duurder dan FC. Het lijkt me ook dat FC aan de client-zijde minder overhead heeft dan een file sharing protocol.

Ik raad aan om alleen 8-poort adapters te gebruiken omdat die meer bandbreedte per poort hebben. LSI 1068E of SAS2008 (USAS2-L8e) zijn interessante kandidaten. Beide controllers vind je ook onboard op diverse SuperMicro bordjes. Dan begin je dus al met 6+8=14 SATA poorten.

Je doelt neem ik aan op het gebruik van expanders op de meeste controllers met meer dan acht poorten? Voor de performance lijkt me een expander niet zo'n issue. Sas schaalt erg goed en het transfer rates van harde schijven zijn veel lager dan die van een sas-poort. Wel is het zo dat expanders vaak veel energie gebruiken en ook niet erg goedkoop zijn, zodat je net zo goed twee 8-poorts hba's kunt gebruiken.

Gezien het feit dat ik al vijf Vertexen heb die een leuke L2ARC kunnen vormen, ik nog een ssd voor de ZIL nodig heb en ik minimaal acht maar liever twaalf harde schijven wil kunnen aansluiten lijkt het met beter om twee 8-poorts hba's te kopen of een extra sas hba naast een onboard sas-controller.

Supermicro heeft leuke betaalbare bordjes voor single socket Sandy Bridge Xeons. Qua geheugen zit ik dan wel aan maximaal 16GB omdat 8GB unbuffered dimms nog erg duur zijn. Als ik een socket 1156-mobo neem voor de Xeon 3400 kan ik er 32GB registered geheugen in kwijt wat nu zo'n 280 euro kost. Deze oudere processors hebben neem ik aan een wat hoger energieverbruik. Een klein nadeel hiervan is dat ik ook helemaal geen sata 600-poorten zal hebben. Een losse sas 6G-adapter is op dit moment nog een stuk duurder dan een sas 3G-adapter.

Het liefst wil ik twaalf harde schijven kunnen aansluiten (zoveel hotswap bays heb ik al) dus ik denk dat ik er dan maar twee goedkope 8-poorts sas-adapters bij haal om het totaal aantal poorten op 22 te brengen. Zo kan ik de 30GB Vertexen die ik al heb blijven gebruiken. Ik zou zelfs genoeg poorten hebben om mijn Mtron Mobi's aan de L2ARC toe te voegen. In totaal zou ik dan zo'n 200GB aan capaciteit hebben in de L2ARC. Ik hoef dan alleen nog maar geld uit te geven aan een Intel SSD 320 voor de ZIL.

Ik zat te kijken naar Nexenta en dat ziet er wel makkelijk uit qua beheer.

Q schreef op vrijdag 29 juli 2011 @ 00:42:
Leuke uitdaging!

Letop dat OpenSolaris officieel dood is. OpenIndiana is de community voortzetting er van maar ik zou mijn storage niet aan zo'n klein platform toevertrouwen.

Wikipedia: OpenSolaris

Effectief ga je twee systemen als 1 systeem maken. 1 systeem als computer, 1 systeem als storage. Een goede UPS zou dan wel fijn zijn. Door met 2 systemen te gaan werken heb je 2x zoveel kans op ellende.

Ik heb zelf een tijdje timemachine over iSCSI gedraaid en ik heb een keer mee gemaakt dat ik met een volledig corrupte TM disk zat door netwerk problemen.

Mijn vertrouwen in de performance van een NAS is op dit moment nul. SMB file sharing op een Mac werkt nog trager dan op Windows. Ik wil DAS-like performance maar dan geconsolideerd.

Ik weet niet of je de Mac Pro al hebt gekocht, maar zo'n ding is zo duur, waarom niet een iMac? Als je nog even geduld hebt komt er wel een thunderbolt oplossing waarmee je snelle storage aan je mac kunt koppelen. Geldt mogelijk ook voor de mac pro, het is wat je wilt. Prive vind ik zaken als geluidsproductie en een groot scherm ook belangrijk.

De Mac Pro heb ik al gekocht en ga ik vandaag ophalen. Ik heb twee 30 inch Cinema Displays en die wil ik blijven gebruiken. Tevens wil ik de mogelijkheid hebben om nog wat aan de hardware te knutselen, bijv. waterkoeling erin bouwen, de cpu upgraden en er veel geheugen in douwen. Een Mac Pro biedt meer mogelijkheden dan een iMac.

Je gaat voor een DAS/SAN achtige oplossing, Maar zou de FC oplossing niet mooi zijn om als basis te gebruiken om IP over te doen en daar dan gewoon SMB of AFP over te draaien? Test het eens, wie weet heb je dan toch snelle storage, maar niet de complexiteit van een SAN oplossing.

Je introduceert ook weer complexiteit (IP over FC laag) en zal waarschijnlijk het snelheidsvoordeel van FC teniet doen. FC is veel efficiënter dan ethernet omdat het flexibele packetgroottes tot 64KB kan verwerken per interrupt waar ethernet jumbo frames fixed 9K doet.

Sun verkoopt SAN-systemen op basis van FC en Solaris voor de enterprisemarkt. Erg gammel kan het niet zijn zou ik denken.

[DrFlash]

Om het simpel te brengen, iscsi wil je niet tenzij je niet anders kan. je verliest veel van de voordelen die zfs brengt, terwijl je wel de nadelen houd.

Op mac is het aan te raden gewoon NFS te doen, voor windows 7 is SMB performance heel redelijk.

Als OS kan ik je ook nexenta (core) aanraden, eventueel met napp-it. het is wat sneller als BSD met toch te voordelen van een gnu (debian) omgeving op de solaris kernel.

[FireDrunk]

8GB UDIMM bestaat niet... 8GB reepjes zijn per definitie registered.
Ik denk bevondien dat je die mooie quad poort FC adapters niet kan trunken, je gaat dan dus maar de bandbreedte van 1 link halen.

ZFS is leuk, maar bedenk je wel dat je vast zit aan FreeBSD of Solaris (en geen Unix / OSX dus).

Je kan als je veel geheugen en toch een beetje zuinigheid wil, misschien ook de nieuwe generatie Opterons overwegen met een SR56** chipset. Die kunnen 64GB of 128GB geheugen aan.

In het 10TB+ Storage topic heeft iemand zo'n systeem gepost, check die maar eens.

[Q]

Femme schreef op vrijdag 29 juli 2011 @ 09:34:
Mijn vertrouwen in de performance van een NAS is op dit moment nul. SMB file sharing op een Mac werkt nog trager dan op Windows. Ik wil DAS-like performance maar dan geconsolideerd.

Wat is de toepassing: video bewerken, of veel grote bestanden die je moet overzetten?

De Mac Pro heb ik al gekocht en ga ik vandaag ophalen. Ik heb twee 30 inch Cinema Displays en die wil ik blijven gebruiken. Tevens wil ik de mogelijkheid hebben om nog wat aan de hardware te knutselen, bijv. waterkoeling erin bouwen, de cpu upgraden en er veel geheugen in douwen. Een Mac Pro biedt meer mogelijkheden dan een iMac.

Ok.

Je introduceert ook weer complexiteit (IP over FC laag) en zal waarschijnlijk het snelheidsvoordeel van FC teniet doen. FC is veel efficiënter dan ethernet omdat het flexibele packetgroottes tot 64KB kan verwerken per interrupt waar ethernet jumbo frames fixed 9K doet.

Als je de oplosing als DAS gaat gebruiken, ja. Je IO zal er onder lijden. Als NAS zou het niets uitmaken.

Sun verkoopt SAN-systemen op basis van FC en Solaris voor de enterprisemarkt. Erg gammel kan het niet zijn zou ik denken.

Dat is een server / datacenter omgeving waarbij een aantal aannames gelden. Server hardware, UPS, 24/7, etc. Een thuis situatie is net even anders. Stroom uitval, kat die op kabel knaagt. Weet ik het. Met NAS is dat geen issue. Met DAS wel. NAS is enkele file corrupt. DAS = hele disk corrupt.

Maar het mooie is dat je flexibel bent met FC. Je kunt altijd nog switchen van DAS naar NAS mocht je dat willen.

Ik moet erkennen dat de SMB performance van de mac niet bijster goed is. Ik ga zelf nog eens kijken hoe dat getweaked kan worden en of NFS nog qua usability een optie is.

Ik heb het idee dat je het jezelf wel moeilijk maakt, maar daarin ligt misschien ook gewoon een leuke uitdaging. En ik ben zeker benieuwd naar de resultaten met FC.


BTW:

http://communities.intel....ad/22227?start=0&tstart=0

[ Voor 9% gewijzigd door Q op 29-07-2011 13:23 ]

[Femme]

FireDrunk schreef op vrijdag 29 juli 2011 @ 10:01:
8GB UDIMM bestaat niet... 8GB reepjes zijn per definitie registered.
Ik denk bevondien dat je die mooie quad poort FC adapters niet kan trunken, je gaat dan dus maar de bandbreedte van 1 link halen.

Ik heb inmiddels gevonden dat je voor het loadbalancen van FC-poorten ondersteuning voor MPIO (multipath I/O) nodig hebt. MacOS X heeft het standaard in de scsiport driver. Solaris/Nexenta, Linux en Windows kunnen het ook allemaal. Hier is de handleiding voor Nexenta.

ZFS is leuk, maar bedenk je wel dat je vast zit aan FreeBSD of Solaris (en geen Unix / OSX dus).

Of Solaris een probleem gaat zijn voor mij kan ik niet goed inschatten. Ik heb wel gewoon basis Linux-ervaring en ik heb een tijdje Ubuntu gedraaid wat prima ging mede dankzij de overdaad aan tutorials die er online zijn te vinden. Voor Solaris zal dat wellicht minder zijn.

Nexenta ziet eruit als een gebruiksvriendelijke oplossing.

Je kan als je veel geheugen en toch een beetje zuinigheid wil, misschien ook de nieuwe generatie Opterons overwegen met een SR56** chipset. Die kunnen 64GB of 128GB geheugen aan.

De Supermicro H8SGL-F lijkt me een erg mooi bordje met acht dimm-slots. Een configuratie met dit mobo, 32GB RAM en een 8-core Opteron wordt wel wat duurder (ca. +250 euro) dan een eenvoudiger Sandy Bridge-systeem met 16GB RAM.

Q schreef op vrijdag 29 juli 2011 @ 13:17:
[...]

Wat is de toepassing: video bewerken, of veel grote bestanden die je moet overzetten?

Photoshoppen, foto's bewerken, videobewerken (vaak ook met lossless compressed video als tussenstap).

Dit is echter niet zo heel erg boeiend. Ik wil gewoon bruut snelle opslag waar ik nooit voor hoef te wachten. ZFS wil ik gebruiken als alternatief voor een hardware raid-controller, met name vanwege de cachingmogelijkheden. Het alternatief is een raid-adapter met ssd-caching. Zo'n adapter kost meer dan 1000 euro (inclusief softwarelicentie voor Adaptec MaxCache of LSI CacheCade) en is minder flexibel dan ZFS. Ik zit dan opgescheept met lokale opslag in mijn Mac en dat wil ik niet vanwege het geluid en het gebrek aan ruimte in de behuizing. Ik zou de storage dan ook niet kunnen samenvoegen met die van m'n server. Het lijkt me ook leuker om een brute ZFS-doos te bouwen. Dat laatste is eigenlijk het belangrijkste argument. Ik doe dit niet omdat het nodig is, dan zou ik met de twee 1TB-harde schijven die nu in de Mac Pro zitten ook wel uitdunnen.

Ik zoek in principe dus een alternatief voor DAS dat minimaal vergelijkbaar kan presteren aan een interne raid-adapter met ssd's en harde schijven. Ik heb mijn twijfels of dat met een NAS gaat lukken maar ik laat me graag verrassen. De machine moet ook voor NAS-server gaan spelen dus dan zal ik alsnog zien of dat presteert over gigabit ethernet.

Dat is een server / datacenter omgeving waarbij een aantal aannames gelden. Server hardware, UPS, 24/7, etc. Een thuis situatie is net even anders. Stroom uitval, kat die op kabel knaagt. Weet ik het. Met NAS is dat geen issue. Met DAS wel. NAS is enkele file corrupt. DAS = hele disk corrupt.

In alle jaren dat ik Windows-pc's heb laten crashen is het me nog niet gelukt om een disk compleet corrupt te maken. Als je moet vertrouwen op UPS'en om je bestandssystemen heel te houden heb je denk ik teveel vertrouwen in de stroomvoorziening van een datacenter.

Voordat ik er belangrijke data op zet zou ik eens kunnen proberen wat er gebeurd bij stroomuitval van één van de machines.

[Anoniem: 15758]

Femme schreef op vrijdag 29 juli 2011 @ 09:34:
Daar staat tegenover dat ik met fibre channel op een goedkopere manier (met refurbished enterprise hardware) aan een snelle verbinding tussen client en server kan komen. 10GbE is zo'n 500 euro duurder dan FC.

Dat lijkt mij de hoofdreden te zijn om voor een SAN setup te gaan; anders leek een NAS setup via NFS me een veel snellere en betere optie, omdat je files dan op ZFS staan in plaats van een enorm HFS filesystem als file op een ZFS filesystem.

Je doelt neem ik aan op het gebruik van expanders op de meeste controllers met meer dan acht poorten? Voor de performance lijkt me een expander niet zo'n issue.

Normaal is dat niet zo'n issue maar ZFS heeft hier meer last van dan welke setup dan ook. RAID-Z betekent dat per I/O request alle disks betrokken worden, en die I/O is pas klaar als alle disks hun data retourneren. De zwakste schakel dus. Expanders verhogen de latency en verlagen dus ook direct de performance; met bandbreedte heeft het niets te doen.

Gezien het feit dat ik al vijf Vertexen heb die een leuke L2ARC kunnen vormen, ik nog een ssd voor de ZIL nodig heb en ik minimaal acht maar liever twaalf harde schijven wil kunnen aansluiten lijkt het met beter om twee 8-poorts hba's te kopen of een extra sas hba naast een onboard sas-controller.

Lijkt mij een prima setup; en misschien een Intel 320 120GB + firmware fix als SLOG? Of wachten op de Intel 720 als je echt high-end SLOG wilt hebben.

De setup die je nu voorbereid zal zijn:

ZFS filesystem -> ZVOL -> iSCSI-target -> Fibre Channel -> iSCSI-initiator -> HFS filesystem

Je HFS filesystem zal flush commando's sturen om niet corrupt te raken (de metadata in sync laten blijven met de data). Om enigszins zekerheid te hebben dat straks je hele volume niet corrupt raakt, kun je de ZVOL regelmatig snapshotten. Dat heeft wel een peformanceimpact: ZFS kan met deze setup geen snapshots doen op files maar alleen op één grote blok data van meerdere terabytes. Na verloop van tijd zal dit een zware aanslag op de SLOG brengen. L2ARC+SLOG is dus je life-saver voor performance, want zonder die features zal zo'n setup tot onder de 10MB/s kunnen degraderen doordat de schijven continu aan het seeken zijn.

Het zou mooi zijn als je maximaal twee snapshots onderhoudt en deze regelmatig (middels een script?) weer verwijdert. Teveel snapshots verlaagt je write performance aanzienlijk.

Ik heb niet bijster veel ervaring met SAN setups, maar ik vermoed wel dat je hier alle performancefeatures nodig hebt om zowel veiligheid als performance op lange termijn te waarborgen. Zo'n setup kan gemakkelijk extreem traag worden als je HDDs continu moeten seeken. In het begin merk je daar weinig van, maar naarmate je genoeg random writes naar je volume hebt gedaan in combinatie met grote snapshots ga je de overhead daarvan waarschijnlijk wel merken.

Hoe dan ook, ik ben erg benieuwd naar je bevindingen; zodra je deze setup werkend hebt zijn benchmarks dan ook zeer welkom! Misschien benchmarks in het begin op een leeg volume, en later als je het zaakje al redelijk gevuld hebt. Zo kun je de decline in performance bijhouden en wellicht bijsturen op gezette tijden. Bijvoorbeeld je kunt het eerst doen met een Intel 320 120GB SLOG disk en later een Intel 720 SSD nemen met 1800MB/s write throughput en veel random write IOps. Dat laatste zal zeker helpen als je de SLOG veel nodig hebt.

[Femme]

Voor de storage die via FC aan de Mac Pro komt te hangen heb ik aan 2TB opslagcapaciteit voorlopig meer dan genoeg. 2TB harde schijven kosten bijna niets meer. Als ik wekelijks een volledige kopie van het volume zou kunnen maken en in de tussentijd bijv. dagelijkse snapshots kan bijhouden dan zou dat meer dan genoeg zijn. Die snapshots kunnen dan toch ook niet erg uit de hand lopen als ze niet verder dan een week terug gaan?

Ik wil er idd nog een SLOG-drive in zetten wat waarschijnlijk een Intel SSD 320 wordt. Als ik het goed begrijp gaat het merendeel van de capaciteit hiervan dus nutteloos gebruikt worden in Nexenta wat wel jammer is. Een SSD 320 40GB heeft lage schrijfsnelheden en een SSD 311 20GB heeft geen supercap, anders zou die een goede oplossing zijn geweest.

[Anoniem: 15758]

Mja inderdaad; die 311 was eigenlijk wel mooi geweest in jouw geval. En een Intel 320 40GB levert weer erg weinig write throughput.

Enig alternatief zou zijn om toch naar FreeBSD platform te kijken. Maar dat zou ik niet doen als dat de enige reden zou zijn. Als je de voorkeur geeft aan Nexenta zou ik dus je verlies nemen wat betreft de SLOG. Voordeel is wel dat je met 90%+ spare space niets tekort komt.

[Mafketel]

Femme schreef op vrijdag 29 juli 2011 @ 09:34:
[...]
Een losse sas 6G-adapter is op dit moment nog een stuk duurder dan een sas 3G-adapter.
[...]

Vindt ik wel meevallen zeker gezien de prijzen en dingen die wilt aanschaffen voor dit project.

#	Product	Prijs	Subtotaal
1	Supermicro -USAS2-L8i 8-Port SAS/2	€ 159,-	€ 159,-
1	Supermicro AOC-USAS-L8i	€ 114,90	€ 114,90
Bekijk collectie Importeer producten		Totaal	€ 273,90

En wat betreft expanders versus portmultipliers .... Bedenk dat die port multipliers een sata link vermeerderen terwijl een sas expander aan line based switching doen en dus kort een willekeurige hba lijn knopen aan een schijf lijn. Wat dus veel effectiever is. oftewel sata port multiplier doet dit 8 * 1:3 terwijl sas met expander dit doet 8:24. Zou je dit met 1:3 overhead doen, natuurlijk kunnen de meeste port multiplier 4 of 5 schijven aanspreken maar sas expanders hebben over het algemeen 32 kanalen wat dus in die 8+24 wordt verdeeld.
En de lijn die gemaakt wordt is zo snel als de zwakste schakel dus sata600 schijven kunnen dus sneller hun data kwijt op een sas 6g verbinding en houden de lijn dus korter bezet.
Scenario ... hba vraagt aan expander een lijntje naar schijf x en stuurt een aantal request naar deze schijf en heeft daarvoor even een lijntje bezet, nadat dit bij schijf x is gedropt wordt dit lijntje afgesloten en kan er iets anders gebeuren. een andere schijf die inmiddels data heeft klaarstaan om te versturen of een request voor data aan een andere schijf of data voor de schijf. Als schijf x waar de request naar toe was gestuurd zijn data klaar heeft vraagt ie weer aan de expander om een lijntje en verstuurt daar zijn data over naar de hba.

Voor harde schijven heeft een expander dus nauwelijks impact op de snelheid omdat je dus tijdens de schijf latency zat andere dingen kunt doen en je bottleneck niet op een lijn zit maar op 4 of 8 lijnen(hangt af hoe je het aansluit). Op dat punt zit je ook bijna op de verzadigings snelheid van je pcie connectie.

Spreek je over ssd aansluitingen die kun je idd beter wel 1:1 aansluiten en daar heb je dan de onboard sata aansluitingen voor. Mochten die gebruikt zijn dan is een 8 poorts sas kaartje haast niet duurder als een sata oplossing dus lekker voor sas kiezen.

[Femme]

Mafketel schreef op zaterdag 30 juli 2011 @ 10:40:
[...]

Vindt ik wel meevallen zeker gezien de prijzen en dingen die wilt aanschaffen voor dit project.

Die Supermicro -USAS2-L8i valt inderdaad wel mee qua prijs .

[Femme]

Ik heb inmiddels twee QLogic QLE2464 quad port 4Gb fibre channel host adapters binnen. Helaas blijkt er geen driverondersteuning te zijn voor MacOS X Lion dus nu heb ik toch een duurdere Apple hba moeten kopen op eBay. Gelukkig vond ik een gebruikt exemplaar voor 500 dollar (een nieuwe kost ca. 1000 euro). De QLogic's waren 275 dollar per stuk. Als iemand nog een quad-port fc-adapter nodig heeft dan heb ik er nog een in de aanbieding .

Een ZFS-server bouwen blijft in ieder geval goedkoper dan pure ssd-storage in de Mac Pro stoppen. Dat is nogal een dure grap als je minimaal 1TB nodig hebt in raid 5. De flexibiteit is ook gering: meer storage kost meteen veel knaken.

Na wat uitzoekwerk wil ik voor de ZFS-server de volgende hardware gaan gebruiken:

- Tyan S8010 met onboard LSI SAS2008 6Gb sas-controller



- AMD Opteron 4170 HE (2,1GHz hexacore)
- 4x Kingston 8GB DDR1333 ECC Registered
- Areca ARC-1680 met 2GB RAM en battery backup unit
- 4x Mtron Mobi 3000 16GB in raid 10 op de Areca met twee volumes waarvan één voor boot en de ander voor ZIL
- 5x OCZ Vertex 30GB voor L2ARC
- 8x Western Digital WD20EARS in twee volumes (waarvan één voor backup)

Bij nader inzien lijkt het me handiger om een raid 10 van de Mtron's aan de Areca ARC-1680 als ZIL en bootdrive te gebruiken. Op die manier heb ik geen aparte bootdrives nodig (kost twee poorten) en de Areca biedt zeer lage latency op schrijfacties naar de cache op de controller. De bandbreedte van de write-cache is circa 800MB/s. Aangezien ik de controller en de ssd's al heb liggen lijkt me dit een snellere en veiliger oplossing dan een losse ssd aanschaffen voor de ZIL.

Het Tyan-bord heeft zes dimm-slots en ondersteuning voor registered geheugen, zodat je er 8GB modules in kunt zetten. Dat is niet mogelijk met Xeon E3-1200-bordjes.

[voodooless]

Anoniem: 15758 schreef op maandag 25 juli 2011 @ 10:49:
Solaris kan SSDs niet voor meerdere functies gebruiken. Je kunt een SSD dus of voor booten gebruiken, of voor L2ARC, of voor SLOG. FreeBSD kent die beperking niet en je kunt één SSD voor drie of zelfs meer taken gebruiken.

Ik weet niet hoe het met OpenSolaris ziet, maar met OpenIndiana (icm napp-it) kan dat wel: Je moet daar wel wat gekke dingen voor doet, maar het kan..

zpool status
  pool: rpool1
 state: ONLINE
 scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        rpool1      ONLINE       0     0     0
          c2t2d0s0  ONLINE       0     0     0

errors: No known data errors

  pool: tank
 state: ONLINE
 scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c2t0d0  ONLINE       0     0     0
            c2t1d0  ONLINE       0     0     0
        cache
          c2t2d0p2  ONLINE       0     0     0

Als je voor iSCSI gaat zou ik je willen aanraden om goed te kijken naar een initiator voor OSX. Ik gebruik momenteel de GlobalSAN initiator. Deze werkt op zich wel, maar ik vind hem niet echt optimaal stabiel. Vooral als je je Mac wil laten slapen zou ik hem niet aanraden. Ik denk dat ik dat zou kiezen voor een hardware initiator als het budget het toelaat.

Edit: zo te zien heb je al een HW HBA

[Femme]

Ik ga fibre channel gebruiken wat probleemloos zou moeten werken onder OS X. Aan de andere kant zorgt Comstar onder Solaris-afgeleide besturingssystemen voor het beschikbaar stellen van een fibre channel target.

Ondertussen heb ik ook weer wat geleerd over multipath I/O in MacOS X.

MacOS X Lion heeft ondersteuning gekregen voor T10-gestandaardiseerde ALUA (asymmetric logical unit access) multipathing. ALUA wordt ook door Solaris ondersteund. Oudere versies van MacOS X hadden een afwijkende vorm van multipathing die alleen met bepaalde fibre channel hardware samenwerkte. Zonder multipathing kan ik de vier poorten op de fibre channel adapters niet tegelijkertijd gebruiken of ik zou vier volumes met ieder een eigen LUN moeten stripen onder OS X, wat nogal omslachtig zou zijn.

ALUA maakt het trouwens ook mogelijk om een volume zowel als fibre channel als iSCSI target beschikbaar te maken. Daarmee zou ik een volume moeten kunnen mounten op een MacBook als hij niet is gemount op de Mac Pro.

[SpamLame]

Anoniem: 15758 schreef op maandag 25 juli 2011 @ 10:49:


Now i'm confused! FC = netwerk, iSCSI = protocol/service over het netwerk. Wat bedoel je precies? Of bedoel je van die FibreChannel insteekkaarten die een hardeschijf presenteren en dus hardwarematig iSCSI implementeren? Dat laatste heb ik geen ervaring mee; ik zou het op open source technieken houden.

Denk dat Femme bedoelt FCP in te zetten hoewel met FC vaker zowel het netwerk als transportprotocol aangeduid kan worden.

Anoniem: 15758 schreef op zaterdag 30 juli 2011 @ 08:35:

Lijkt mij een prima setup; en misschien een Intel 320 120GB + firmware fix als SLOG? Of wachten op de Intel 720 als je echt high-end SLOG wilt hebben.

De setup die je nu voorbereid zal zijn:

ZFS filesystem -> ZVOL -> iSCSI-target -> Fibre Channel -> iSCSI-initiator -> HFS filesystem

Dit iets wat niet mogelijk is tenzij je IP over FC gaat doen, iets wat zelden gedaan wordt maar niet onmogelijk is.
iSCSI is SCSI pakketten in IP gepakt waarbij wel dezelfde mechanieken gebruikt worden zoals bij FC(P).
Fibre Channel een netwerktechniek.
Tenzij je wellicht FCP bedoelde, maar dat is een transportprotocol die in de regel alleen SCSI pakketten vervoert.

De transport keten zou kunnen zijn
iSCSI-target -> IPoFC > Fibre Channel -> IPoFC > iSCSI-initiator of
FCP target > Fibre Channel -> FCP initiator

De onderste zou makkelijker te realiseren kunnen zijn.
Je Mac is de initiator en op je server stel je je software in als target, helaas heb ik daar weinig mee gewerkt en kan er verder ook niks zinnigs over zeggen.
Indien je geen FC switch gebruikt kan het zijn dat je de HBA's in point-to-point modus moet zetten als ze dat niet zelf detecteren. In de regel staat de HBA in Switch Fabric modus of FC-SW then FC-P2P.

[Femme]

Het maakt geen sense om iSCSI via IP over FC op een FC-netwerk te gebruiken als je ook direct fibre channel protocol kunt praten. De Mac kan booten vanaf de fibre channel hba wat het helemaal leuk zou maken (systeem wordt dan diskless).

Een FCP-target maken in Solarisachtigen kan met Comstar. iSCSI zou ik eventueel kunnen gebruiken om hetzelfde volume ook beschikbaar te maken voor mijn MacBook Air die geen FC heeft.

[SpamLame]

Femme schreef op dinsdag 30 augustus 2011 @ 10:06:
Het maakt geen sense om iSCSI via IP over FC op een FC-netwerk te gebruiken als je ook direct fibre channel protocol kunt praten. De Mac kan booten vanaf de fibre channel hba wat het helemaal leuk zou maken (systeem wordt dan diskless).

Helemaal met je eens, reageerde ook op CiPHER reactie waarin hij de volgende setup schetst

• ZFS filesystem -> ZVOL -> iSCSI-target -> Fibre Channel -> iSCSI-initiator -> HFS filesystem

Als je direct FCP kan gebruiken geniet dat de voorkeur.
Evenwel is het (theoretisch) mogelijk om iSCSI over IP over FC te gebruiken.

Een FCP-target maken in Solarisachtigen kan met Comstar. iSCSI zou ik eventueel kunnen gebruiken om hetzelfde volume ook beschikbaar te maken voor mijn MacBook Air die geen FC heeft.

[Q]

Is het voordeel van de iSCSI laag niet dat je in de toekomst flexibeler bent met je hardware? Je kunt dan FC door iets anders vervangen (mocht dat boeien) zonder dat je setup echt wordt aangepast. Zolang die setup maar werkt met iSCSI. De hogere latency en lagere performance tov bare metal moeten daar wel tegen opwegen.

In mijn PC verleden heb ik, behalve eens een extra disk of wat extra RAM mijn computers altijd in zijn geheel vervangen en nooit geüpgraded. In die zin zou het dan niet zo interessant zijn. Tegen die tijd dat een transitie wenselijk is, zie je het dan wel weer.

[ Voor 44% gewijzigd door Q op 30-08-2011 14:05 ]

[Femme]

De flexibliteit om verschillende scsi transport protocollen te gebruiken heb je sowieso in een Solaris-achtige. Een scsi-target wordt in Solaris verzorgd door Comstar (common multiprotocol scsi target). Comstar kan hetzelfde volume via verschillende scsi transport protocollen beschikbaar maken, dus als je later wil switchen van fibre channel naar iscsi of sas kan dat.

[Q]

Ok dat wist ik niet, dat is super, dan maakt de fabric niet uit en blijf je flexibel naar de toekomst. Tnx voor de uitleg.

[Juup]

Klein beetje offtopic, betreffende SMB performance op OS X:

Met deze hint: 10.6: Slow SMB browsing of Windows Servers fixed is de performance op m'n Snow Leopard install een heel stuk verbeterd.

Deze 2e hint: Speed up SMB (Samba) server performance heb ik nog niet geprobeerd.

[Femme]

Ik heb weer wat verder zitten zoeken naar de hardware die ik wil. Ik heb besloten dat ik geen gare build wil met 2,5 inch drives die los in een kast liggen en dergelijke. Er moet een mooi kastje omheen waar alles in past en dat gaat niet lukken in mijn huidige Chenbro SR107 met acht hotswap bays + extra 4-in-3 hotswap bay. In rackmount in een hippe LackRack lijkt me wel leuk.

Vanwege het schrale aanbod van gebruikte rackmounts in Nederland ging ik kijken op de Duitse eBay waar wel wat leuks staat. Helaas willen veel Duitsers om onduidelijke reden niet naar Nederland verzenden. Deze aanbieding van een Chenbro RM414 voor € 199 is leuk maar die Duitser wil dus niet naar Nederland versturen en reageert ook niet op vragen hieromtrent.



Ik had al bedacht dat ik 'm mooi hadden kunnen modden zodat er een extra 5,25 inch drive in kan. Ik wil er namelijk twee van deze hotswap bays voor 2,5 inch drives in stoppen:



De andere RM414's op eBay waren allemaal een stuk duurder en de hotswap bays waren niet compleet of er zaten gedeeltelijk scsi-backplanes in. Kost nog weer meer om dat te fixen.

Toen bedacht ik me om maar eens naar Norco te kijken aangezien die tegenwoordig vaak wordt genoemd door nasbouwers. Norco heeft de RPC-4116 en RPC-4216 die precies doen wat ik wil: zestien 3,5 inch hotswap bays en twee 5,25 inch bays voor de 2,5 inch ssd's. De prijs van ca. 350 euro is ook nog eens schappelijk. Voor hetzelfde bedrag heb je een incomplete Chenbro RM414 met weliswaar een redundante voeding. Die wil je echter toch niet gebruiken in een thuisomgeving vanwege het staaljagergeluid dat eruit komt.



Mijn aandacht werd nog even afgeleid door de brute RPC-4164 waar 64 2,5 inch drives in kunnen. Ik heb al lange tijd een voorliefde voor 2,5 inch harde schijven vanwege het geringe energieverbruik en compacte formaat. Een build waarin je die kast een beetje redelijk zou vullen met 24 tot 32 harde schijfjes zou echter wel erg duurder worden. Niet alleen vanwege de harde schijven maar ook omdat je een enorm aantal sas/sata-poorten nodig hebt waardoor je dure expanders moet gebruiken.



Na wat meer gelezen te hebben over de prestaties van de verschillende soorten vdevs in ZFS ben ik tot de conclusie gekomen dat ik mirroring moet gebruiken voor goed schalende prestaties. Dat is op zich geen probleem omdat ik niet zo heel veel capaciteit nodig heb. Ik heb ongeveer 4TB nodig en dat ik wil minimaal twee keer kunnen backuppen. In plaats van mijn huidige vier 2TB WD20EARS zou ik mijn vier 1,5TB Barracuda's LP kunnen uitbreiden naar een mirror van twaalf stuks met een capaciteit van 9TB. Mijn huidige schijven zijn wel trager dan de Barracuda's 5900.3 die je nu nieuw koopt dus ik weet nog niet of dat verstandig is. De vier WD20EARS zal ik dan wel in RAID-Z draaien en gaan alleen backups bevatten. Ik zou ook de Barracuda's LP kunnen verkopen en er nieuwe schijven voor in de plaats kunnen terugkopen.

Om aan genoeg poorten te komen heb ik dan nog een Intel SASUC8I nodig.



In totaal krijg ik dan 30 poorten (6x sata-3g onboard, 8x sas-6g onboard, 8x sas-3g op de Areca-raid-controllerzil-accelerator en 8x sas-3g op de Intel-hba). De behuizing krijgt zestien 3,5 inch bays en twaalf 2,5 inch bays. Ik heb dan nog drie bays vrij voor eventuele extra ssd's. Ik ga eerst maar eens kijken hoe snel de L2ARC zich zal vullen met de vijf Vertexjes van 30GB.

Is onderpartitioneren makkelijk mogelijk? Tot nu heb ik altijd effectief maar 25GB gebruikt op de Vertexen omdat ze veel last hebben van performancedegradatie bij een maximaal gebruik van de capaciteit.

Op de Areca wil ik alleen de Mtron's aansluiten die voor de zil gebruikt gaan worden. De Areca heeft de vervelende gewoonte om bij het flushen van de cache helemaal op slot te gaan totdat de write-cache leeg is. Hoe groter de cache, hoe langer de wachttijd. Dit wil je dus niet combineren met drives die voor leesoperaties worden gebruikt. Bij writes die plaatsvinden in burst zou de cache op de Areca in ieder geval goed moeten helpen om de latency te verlagen.

[ Voor 12% gewijzigd door Femme op 02-09-2011 22:13 ]

[FireDrunk]

Alles wat je schrijft als cache, moet toch ooit weer gelezen worden om naar disk te gaan...
Als jou Areca op slot gaat bij een write flush, kan ZFS dus ook niet meer uit het DRAM geheugen lezen?
Dat is nou juist leuk... Je hebt eigenlijk een ZIL in memory, maar als je meer schrijft dan het DRAM geheugen van je Areca gaat het naar SSD (wat random nog steeds leuk is). Maar als jou Areca niets meer doet tot het hele cache leeg is, ga je niet veel meer performance winnen dan gewoon een losse SSD denk ik

[Femme]

Als ik het goed begrijp vinden er geen reads plaats op de zil tenzij de pleuris uitbreekt en het log uitgelezen moet worden. De data blijft gecached in RAM en kan van daaruit naar de disks geschreven worden.

Het blokken van read I/O tijdens het flushen van de cache zou in de nieuwere firmwareversies van Areca verbeterd verholpen moeten zijn. Grote streaming writes gaan direct naar de disks. Als er alleen kleine writes naar de cache van de Areca gaan zou het vollopen van de cache (ik heb 2GB maar er kan ook 4GB op als ik de juiste sticks vind) geen probleem moeten zijn. De ssd's kunnen het dan wel bijhouden met en schrijfsnelheid van ca. 160MB/s.

[FireDrunk]

Mja, in vergelijking tot RAM (ook al is het RAM van je controller) is 160MB/s natuurlijk traag

[Anoniem: 15758]

Het is niet zo dat alle data die je schrijft eerst naar de ZIL wordt geschreven; dan zou je met een SSD van 160MB/s alleen maar 160MB/s kunnen schrijven. Nee, alleen de 'synchronous writes' gaan naar de ZIL. Dat kan maar 1MB/s zijn per 500MB/s ofzo, in een gunstig geval. Het hele punt hierbij is dat de hardeschijven geen kleine random writes tussendoor krijgen zodat ze door kunnen gaan met sequential write en dus niet qua performance inboeten met kleinere random writes.

Zeker 4K sector schijven die bij non-aligned random writes een performance hit krijgen omdat ze bij die writes ook nog moeten lezen, kan dit enorm veel impact hebben. De ZIL wordt nooit gelezen, tenzij er recovery plaatsvindt na een stroomstoring dus je kunt rustig zeggen 100% write-only. Een L2ARC is in principe 100% read, echter wordt de L2ARC ook bijgehouden en dat kost je natuurlijk ook writes. Die writes worden 'gecapped' om SSDs die als L2ARC dienen niet teveel te belasten, dat kun je - althans onder BSD - allemaal instellen.

[analog_]

Goedkoopste manier voor 10GBe is Mellanox Infiniband kaartjes op ebay, ben je rond de 200e kwijt all in. Als je overigens ZFS + webinterface zoekt kan je kijken naar NexentaStor, gebruik het zelf nu al één jaar ongeveer en werkt prima. Performance in VM omgeving is wat minder maar ligt eigenlijk voornamelijk aan de web-interface (werkt beter als die ingesteld is singlethreaded). Het doet FC/IB/CIFS en FTP en in een Windows omgeving kan je ook gebruik maken van de extended ACLs (even uitgebreid als NTFS of EACL op *nix) en deze aan een LDAP/AD server koppelen.

[ Voor 88% gewijzigd door analog_ op 03-09-2011 04:33 ]

[Femme]

Infiniband heb ik naar gekeken maar ik vond de ondersteuning in OS X nogal schimmig. Voor in een Windows- of Linux-pc zou het wel een oplossing kunnen zijn.

[Anoniem: 6137]

Je zou er ook AFP bij kunnen gebruiken en native time machine =)

[Femme]

Ik ga gewoon een tweede volume mounten via fibre channel en daar de Time Machine-backups op doen. Wellicht is het ook zinvol om er dedupe op te doen in zfs?

[Anoniem: 6137]

Femme schreef op zondag 04 september 2011 @ 00:18:
Ik ga gewoon een tweede volume mounten via fibre channel en daar de Time Machine-backups op doen. Wellicht is het ook zinvol om er dedupe op te doen in zfs?

Zeer zeker, voor gezien het feit time machine hele files back-upped als er maar 1 bitje is veranderd, de "dedupniss" om het maar zo te noemen zal dan ook relatief hoog zijn. Let wel dat dedup veel memory gebruikt. In nexenta 3.1 zit een runner die je waarschuwt als de DDT tables en te groot worden voor je memory.

[Q]

w8 even. Ga je de TM backup doen naar het zelfde fysieke systeem?



Als die klapt?

[ Voor 11% gewijzigd door Q op 04-09-2011 21:34 ]

[Femme]

Er komen twee pools in de zfs-bak. Eentje met twaalf Seagate's Barracuda Green als striped mirrors en de andere met vier WD20EARS in RAID-Z. Waar ik de Time Machine backup op ga zetten moet ik nog even over nadenken maar in ieder geval zal dat de twee pool een kopie bevatten van het volume dat via fibre channel op de Mac gemount zal worden.

[FireDrunk]

Ik neem aan dat jij als 'Hardwareconnaisseur' snapt dat er ook zoiets is als virussen/bliksem/klappende voedingen.

[Femme]

Voor dat soort situaties maak ik off-site backups. Als bliksem de storage in je workstation molt zal hij je server ook wel stuk maken lijkt me, dus wat dat betreft maakt het weinig uit dat het allemaal in één systeem zit.

[FireDrunk]

Dan is je antwoord: Offsite Backups. Dan ben ik helemaal tevreden.

Better save than sorry.

offtopic:
sprak degene zonder backups

[Rob]

Ik nam ook aan dat Femme de nodige maatregelen heeft genomen om een lokale BC4 te voorkomen

[Anoniem: 6137]

Als het goed begrijp ga je een back-up maken van je FCP geëxporteerde luns via FCP op een andere pool? Dat is ook niet echt handig als je het mij vraagt. Je kan beter snapshots maken van je primaire FCP lun, daar zijn ze immers voor.

als je dan ruimte te kort krijgt, kan je met zfs send de oudste snapshot naar je andere pool sturen en de oudste snapshot verwijderen.

[Femme]

Dat kan inderdaad en ben ik ook wel van plan om te doen als tweede vorm van backup. Time Machine heeft echter ook zo zijn voordelen qua beheer.

[Mafketel]

Nu zeg je daar wat ...
Onder windows kun je de snapshots bereiken in de explorer door naar previous versions te gaan. Op de mac is er niet zo'n mechanisme zover als ik weet. Zou wel handig zijn.

Al kan je natuurlijk altijd naar de dir .zfs/snapshots gaan

[ Voor 14% gewijzigd door Mafketel op 05-09-2011 07:40 ]

[Femme]

Hij gaat neem ik aan op blokniveau snapshots maken van het volume dat ik via FCP ga exporteren. Behalve tijden van het snapshot krijg ik dan niet meer zinnigs te zien. Time Machine werkt wat dat betreft een stuk handiger omdat ik direct toegang heb tot bestanden en versies van bestanden kan terughalen.

[FireDrunk]

Wat bedoel je met Hij? Zfs maakt op file en blokniveau snapshots... Je kan gewoon een individuele file restoren.

[Femme]

Zfs exporteert een block device via FCP en heeft geen kennis van het bestandssysteem (HFS+) op dat block device.

[ Voor 9% gewijzigd door Femme op 05-09-2011 10:02 ]

[FireDrunk]

Ahzo, dat maakt het weer wat ingewikkeld dunkt me, maar als jij het handig vind

[Anoniem: 6137]

HFS heeft nu toch file versions?

[johnkeates]

Is het niet handiger om ZFS-Fuse i.c.m. MacFuse te gebruiken? Ik weet niet of het op Mac OS X even lekker werkt, maar op Linux doet 't het goed.

[Femme]

Zfs komt niet op de Mac te draaien maar op een aparte doos met Nexenta of OpenIndiana.

FireDrunk schreef op maandag 05 september 2011 @ 10:09:
Ahzo, dat maakt het weer wat ingewikkeld dunkt me, maar als jij het handig vind

Vanuit de Mac gezien wordt het super simpel en ga ik een block device krijgen waar ik vanaf kan booten en die ik kan gebruiken als een normale disk.De zfs-doos heb ik als het goed is geen omkijken naar.

Ik kan ook wel filesharing gaan doen over ethernet. Alles wat ik tot nu toe hebben gezien met SMB onder Windows en Linux zuigt keihard qua performance. Meer dan 40MB/s sustained heb ik eigenlijk nog niet gezien. Piekjes naar 80MB/s en dat is het dan. Dat ga ik dus niet gebruiken als vervanging voor lokale storage.

Met een enkele 4Gb fibre channel poort kan ik al 400MB/s en als multipath I/O gaat werken heb ik in totaal 1,6GB/s tussen de Mac en de zfs-doos. Met een hexacore cpu, 32GB RAM, een striped mirror van twaalf disks, een 200GB grote L2ARC van zes ssd's en een ZIL met een piekbandbreedte van 800MB/s moet het mijn inziens wel mogelijk zijn om degelijke snelheden te gaan halen.

[ Voor 3% gewijzigd door Femme op 07-09-2011 23:58 ]

[FireDrunk]

Klopt, je hebt zeker een mooie build bedacht!
Even tussendoor: >40MB/s kan echt al hoor, zie het grote DIY RAID NAS topic, daar staan meedere mensen (waaronder ikzelf) tussen met >110MB/s.

[Anoniem: 9449]

Ik zat even naar dat Tyan bordje te kijken en toen kwam ik deze tegen:

http://www.newegg.ca/Prod...aspx?Item=N82E16813131670

Is zo te zien goedkoper dan de Tyan, heeft ook SAS en mogelijkheid voor een 2e processor.

[Femme]

Als ik het goed begrijp bevindt de sas-controller zich op een Asus Pike-dochterbord die je er los bij moet kopen. Dat dochterbord kost 300 dollar. Met de Tyan ben je dus alsnog goedkoper uit. Voor een storageserver heb ik ook liever een single socket bord met zes dimm-slots dan een dual socket bord met vier dimm-slots per socket.

http://www.asus.com/Serve...Accessories/PIKE_2008IMR/
http://web.techbuy.com.au.../ASUS/ASPIKE-2008_IMR.asp

[Anoniem: 9449]

Ik ging ervan uit dat die poorten op het bord gewoon zouden werken. Vaag verhaal weer van Asus. In dat geval is jouw Tyan bord i.d.d. verreweg de beste keuze.

[dutch_warrior]

Femme schreef op zaterdag 10 september 2011 @ 20:12:
Als ik het goed begrijp bevindt de sas-controller zich op een Asus Pike-dochterbord die je er los bij moet kopen. Dat dochterbord kost 300 dollar. Met de Tyan ben je dus alsnog goedkoper uit. Voor een storageserver heb ik ook liever een single socket bord met zes dimm-slots dan een dual socket bord met vier dimm-slots per socket.

http://www.asus.com/Serve...Accessories/PIKE_2008IMR/
http://web.techbuy.com.au.../ASUS/ASPIKE-2008_IMR.asp

Klopt ja, de Pike boards zijn echter wel goedkoper te krijgen 140 dollar vanaf newegg, maar het blijft duur.
Deze is misschien ook geschikt maar heb er verder niet veel research naar gedaan dus ik kan fout zitten.

[Femme]

Hier wat plaatjes van de spullen die ik inmiddels binnen heb. Helaas ontbreekt het nog aan een cpu. De Opteron 4170 HE heeft lange levertijden. Wellicht komt dit ook door de hand zijnde release van de Valencia-core.

Tyan S8010 mobo:



QLogic QLE 2464 quad port 4Gb fibre channel host bus adapter:



4x LC-LC optische kabel:



Areca ARC-1680:



5x OCZ Vertex 30GB en 4x Mtron Mobi 3000 16GB. Als het lukt om de Mac van fibre channel te laten booten komt er nog een Crucial m4 64GB in de L2ARC:



4x Kingston 8GB DDR3-1066 ECC Registered:



12x Seagate Barracuda Green 2TB:



Norco RPC-4216:



Er komen nog vier W20EARS bij uit m'n huidige server en ik wacht nog op een extra sas-controller en twee 5,25 inch hotswap bays voor zes 2,5 inch drives.

Voor de Mac heb ik een vierpoorts 4Gb fibre channel hba van Apple gescoord (althans dat was de bedoeling, het presenteert zichzelf als een LSI 7404EP, hardwarematig is hij iig hetzelfde als de Apple oem adapter):

[Femme]

Ik kwam hier en interessant document tegen met wat benchmarks van de random en sequentiële doorvoer van 6Gb sas, 8Gb fc, 10Gb iscsi en 1Gb iscsi op directe en switched verbindingen. iscsi presteert een stuk minder dan sas en fibre channel ondanks de hogere theoretische bandbreedte.

Wat ik wel vreemd vind is dat de directe sas-verbinding een doorvoer haalt van meer dan 1,0GB/s in sommige tests, wat helemaal niet kan op een 6Gbps link. Het lijkt wel alsof men een wide port heeft getest, wat niet vreemd zou zijn gezien externe sas-kabels altijd multilane zijn. Een switched topologie heeft iig nauwelijks invloed op de prestaties.

http://www.flashmemorysum...1/20110809_F1C_Martin.pdf

[ Voor 6% gewijzigd door Femme op 18-09-2011 19:18 ]

[SpamLame]

Jammer dat in die statistieken 10G FCoE mist, dan was het overzicht (wat mij betreft) compleet geweest.

[dutch_warrior]

Ziet er goed allemaal uit, ben erg benieuwd naar het eindresultaat.
Zoals ik een tijdje geleden al in het DIY nas topic had gezegd ben ik benieuwd naar het energie verbruik van het Opteron platform, hoelang wacht je al op de CPU?

[Femme]

Ik ben nu bijna drie weken aan het wachten.

[Q]

Zou je het booten van de FB HBA al kunnen testen met een testbak die de andere kant voor zijn rekening neemt?

[Femme]

Ik heb op dit moment thuis alleen een Atom-mobo in mijn huidige server waar één pci express-slot op zit en die wordt gebruikt door een Areca-controller. Het is nogal een gedoe om hiermee te testen.

[Q]

Ik zou wel ff met medeweten een bordje van de redactie lenen en na het testen weer retourneren. Weet je waar je aan toe bent. Anders respect voor je geduld

[Femme]

Q schreef op maandag 19 september 2011 @ 09:51:
Ik zou wel ff met medeweten een bordje van de redactie lenen en na het testen weer retourneren. Weet je waar je aan toe bent. Anders respect voor je geduld

Ik verwacht niet dat ik niet dat ik met een paar keer klikken een fc target heb gebouwd onder een besturingssysteem en een bestandssysteem dat ik niet ken. Er zal nogal wat uitzoekwerk bij komen kijken. Ik doe dat liever meteen op de hardware die ik wil gebruiken.

De order voor de Opteron 4170 HE heb ik maar gecancelled omdat die stakkers van AMD er niet in slagen een cpu te leveren. Ik heb nu een 4122 besteld die wel op voorraad zou moeten zijn. Hopelijk kan ik er binnenkort een zuiniger en snellere Valencia-proc in stoppen.

Op eBay heb ik nog een paar IBM ServeRAID M1015 en ServeRAID BR10i sas-controllers besteld. De M1015 ga ik in het systeem stoppen en de rest gooi ik in V&A. Als het goed is krijg ik dus twee LSI SAS2008-controllers in het systeem (een op het mobo en de andere als losse hba).

[Femme]

De Opteron 4122 had ik gelukkig al na een dag binnen dus als het goed is kan ik komend weekend gaan bouwen .

[FireDrunk]

Nice! Ben beniewd!

[Ibidem]

Ik zie dat mijn werkgever de 4170 HE Opterons gewoon ruimschoots op voorraad heeft. En dit al geruime tijd! Mocht je meer info willen dan kan je me een DM sturen. Help ik je van daar wel verder indien gewenst.

[Femme]

Ik ga de 4122 niet vervangen door een oude Lisbon-Opteron. Het is momenteel een nogal ongelukkig moment om een Opteron te moeten komen omdat nieuwe Valencia-processors met de Bulldozer-core op het punt staan om uit te komen. Die zullen weer sneller en zuiniger worden.

[dutch_warrior]

Jammer van de 4170HE, maar een valencia CPU kan die tegenvaller straks meer dan goed maken.
ik ben wel geïnteresseerd in een HBA, dus ik wacht je V&A add wel even af .

Ben je eigenlijk nog steeds van plan om een uitgebreid artikel over DIY nas oplossingen te schrijven?

[Q]

Hoe gaat ie?

[Femme]

Ik heb nog geen tijd gehad om het in elkaar te gaan zetten .

Ik heb wel alles bij elkaar incl. een extra IBM / LSI sas 6G hba.

[Q]

Tof. Volgens mij ga je de 1e ter wereld worden met deze setup: een diskloze mac met een hba naar een storage doos.

Neem vakantie

[ Voor 7% gewijzigd door Q op 13-10-2011 13:01 ]

[Femme]

Er zullen wel meer Mac Pro's zijn met fibre channel bij bijvoorbeeld filmproductiebedrijven maar voor thuis zal het niet zoveel gedaan zijn denk ik .

[Staatslot]

En.. inmiddels al tijd gevonden? Ik ben heel erg benieuwd naar ervaringen en foto's

[Femme]

Ik heb de doos gisteren in elkaar gezet. De Tyan S8010 is tot nu een erg vervelend moederbord gebleken. Als je iets verandert aan de hardwareconfiguratie boot hij meestal niet meer en moet je eindeloos klooien met t. Ik snap er nog niet veel van. Ik begrijp ook weinig van de volgorde waarin het geheugen geïnstalleerd moet worden.

De slots zijn genaamd

DIMM_A2
DIMM_A1
DIMM_A0
DIMM_B2
DIMM_B1
DIMM_B0

A2 en B2 zijn blauw, de andere slots zijn zwart.

Dus dan denk je dat je met vier sticks A0, A1, B0 en B1 moet vullen maar dan boot hij niet, ik krijg 'm alleen bootend met de modules in B0, B1, B2 en A0. Bij het booten ziet hij 24GB ipv 32GB. Gisteren had ik per ongeluk in Windows geboot op de oude installatie op mijn Mtrons en Windows zag 32GB waarvan 24GB usable.

Ik ben nu bezig met het updaten van de firmware op de sas-controllers en de fibre channel adapter.

De onboard sas-controller heb ik naar de IT-firmware van de LSI SAS9211-8i geflashed. Om dit voor elkaar te krijgen moest ik eerst de firmware helemaal wissen:

sas2flash.exe -o -e 7

en dan:

sas2flsh -o -f 2118it.bin -b mptsas2.rom

Vervolgens de IBM ServeRAID m1015 met behulp van de instructies en tools op deze pagina gewist en ook hier de IT-firmware van de SAS9211-8i op gezet.

Hierna heb ik de sas controllers eruit gehaald om de fibre channel adapter te flashen maar boot het kutsysteem niet meer. Ik ga die plank maar rma'en want dit is onwerkbaar .

[Q]

Dat is een tegenvaller. Heb je pech of blijkt een google op dat bord vergelijkbare ervaringen op te leveren?

Ik zou het zelf ook niet meer weten met al die hardware. Ik hoop dat het een defect is en niet een issue specifiek voor dat bord.

Anders iets van Supermicro of Intel zelf?

[ Voor 6% gewijzigd door Q op 24-10-2011 00:11 ]

[dutch_warrior]

RMA lijkt me inderdaad verstandig, serverbordjes zijn vaker erg gevoelig qua ram maar de ene keer wel booten en de andere keer niet met dezelfde nieuwe hardware lijkt me niet helemaal juist.

Het is natuurlijk onnodig om te vragen of je andere geheugen configuraties (1 module per kanaal) ook hebt getest..

[Femme]

Ik heb uiteraard allerlei denkbare geheugenconfiguraties getest. Ik heb drie van dezelfde geheugenmodules in de Mac Pro en ze werken daar probleemloos. Ik heb ook nog twee 2GB Kingston ECC registered modules geprobeerd die oorspronkelijk in de Mac zaten en dat hielp ook niet. Dat zijn weliswaar Mac-compatible modules met een temperatuursensor maar ik neem aan dat ze ook in niet-Apple mobo's werken. Een andere voeding hielp ook niet. Ik heb de machine mee naar kantoor genomen waar ik nog wat unbuffered modules kan proberen. Als dat niet helpt moet het de processor of het moederbord zijn.

Het ding doet ook gewoon raar. In eerste instantie piepte hij bij het inschakelen maar dat doet hij nu ook niet meer. Na ongeveer minuut komt er een aanhoudende piep en dat is alles wat hij doet. IPMI werkt wel maar kan geen sensors uitlezen als het bord niet opstart.

Wat betreft het verbruik zat ik op ongeveer 160W bij het aanzetten en 220W als de harde schijven op gingen spinnen. Dat is met drie sas-controllers, de fibre channel adapter en twaalf Barracuda Green harde schijven. Hopelijk brengt AMD binnenkort wat goedkope low power Valencia-cores uit. Ik heb er nu een 4122 in met een TDP van 95W.

De Norco RPC-4216 had ook een bijzondere verrassing in petto. De twee 5,25 inch bays blijken groter te zijn dan 5,25 inch. Er zitten plastic frontjes voor met een klepje voor optische drives. Dat frontje is groter dan 5,25 inch en als je er iets anders dan een optische drive in wilt stoppen sluit dat niet goed aan. Ook heeft het bracket waarin je de 5,25 inch drives moet monteren aan de voorkant een opstaand randje dat ervoor zorgt dat de onderste bays van mijn Chieftec 6x 2,5 inch hotswap drive bay niet open kunnen. Ik kan het hele zaakje omkeren maar dan kunnen de onderste sata-kabels niet aangesloten worden. Ik moet dus met een dremel aan de slag om dat opstaande randje weg te halen.

[ Voor 4% gewijzigd door Femme op 24-10-2011 10:50 ]

[FireDrunk]

Ik heb het even nagekeken in de manual, maar volgens het manual zou je A0, A2, B0 en B2 moeten vullen omdat je dual ranked 1066Mhz geheugen hebt.

De middelste sloten (A1 en B1) ondersteunen alleen Dual Ranked geheugen van 800Mhz.


Source: http://www.tyan.com/manuals/S8010_UG_v1.0.pdf #31

Wat je kan proberen is als je kan booten de geheugen config te forceren op 800Mhz, dan zou je dus alle banken moeten kunnen vullen.

Dit gedrag zie ik overigens wel vaker (terug moeten klokken naar 800Mhz).
De Dell R710 servers die wij hier hebben doen dat ook als je ze vol stopt met geheugen.
Heeft iets te maken met de bus van de CPU om naar 3 DIMM's tegelijk te moeten schrijven.

[ Voor 50% gewijzigd door FireDrunk op 24-10-2011 11:58 ]

[Femme]

Ik heb nog wat uitgeprobeerd maar niets helpt. Ook met unbuffered geheugen boot hij niet.

[DjCoke]

Was erg benieuwd naar dit project. Is het nog levend? Is het gelukt?

[Femme]

Mijn moederbord is naar Taiwan gestuurd en inmiddels zou er weer iets onderweg moeten zijn naar Nederland.

Een kapot moederbord betekent bij Tyan blijkbaar dat je anderhalve maand mag wachten.

[Jaap-Jan]

Da's strakke service voor een DOA...

[FireDrunk]

Maaruh, dat is toch de verantwoording van de leverancier? Niet van de fabrikant?

[Q]

Wat moet dat moederbord daar in Taiwan? Zwemmen?

Ik zou een defect moederbord dat eventueel 'gerepareerd' wordt niet willen hebben om mijn data aan toe te vertrouwen. Of ben ik te zwartkijkerig?

Waar je hem ook besteld hebt, dit is geen service, hadden ze jou gewoon een nieuwe moeten geven en die andere refurbished verkopen. Met levertijden als voor 2200 besteld morgen in huis is dit waanzin.

[ Voor 7% gewijzigd door Q op 10-12-2011 20:12 ]

[Femme]

Ik had mijn tijd gelukkig nodig voor andere dingen zodat ik me niet al te druk heb gemaakt over de trage afhandeling door Tyan. Het moederbord heb ik inmiddels teruggekregen. Somehow zijn kleine Taiwanese vingertjes erin geslaagd om hem te repareren. Het is dezelfde plank met de LSI IT-firmware die ik op de sas-controller had geflashed. Tot nu toe werkt het ding wel.

Volgende week ga ik eens kijken of ik er OpenIndiana op kan zetten en het zfs gebeuren kan configureren. Voordat ik de hardware zelf in gebruik neem wil ik er uitgebreid op gaan testen om o.a. zfs te vergelijken met kant en klare nassen en een zelfbouw Windows-oplossing met een hardware raid-adapter. Areca wil me voorzien van een nieuwe ARC-1882.

[ Voor 6% gewijzigd door Femme op 15-12-2011 13:15 ]

[FireDrunk]

Je weet dan wel dat testen best een lastige opgave is? Omdat het niet echt vergelijkbaar is...

[Q]

Ben benieuwd naar de resultaten.

[Femme]

FireDrunk schreef op donderdag 15 december 2011 @ 16:30:
Je weet dan wel dat testen best een lastige opgave is? Omdat het niet echt vergelijkbaar is...

Wat bedoel je met niet echt vergelijkbaar? Als het file sharing doet via smb of een block level device deelt via iscsi of fibre channel is het toch gewoon vergelijkbaar?

[Femme]

Ik heb er gisteren OpenIndiana opgeknald via installatie vanaf een usb-stick, ging super simpel in een kwartier had ik het draaiend. De onboard en losse pci express sas-controllers heb ik geflashed met de firmware van een LSI SAS9211-8i (beide hebben een LSI SAS2008-controller aan boord). De sas-controllers en de QLogic QLE2464 fibre channel controller werden meteen herkend. De LSI-controller is zo slim dat je via de bios-interface meteen beide controllers kunt beheren.

Ik heb er napp-it op gezet wat er nogal spartaans uit ziet. Ik kan er ook niet alles mee configureren zoals fibre channel targets. Via de command line werkt zfs en comstar eigenlijk super simpel als je de tutorials volgt die her en der zijn te vinden. Ik doe nu daarom alles via de command line zodat ik ook een beter idee heb wat er achter de schermen gebeurt. Een pool bouwen van zes striped mirrors van 2TB schijven met vijf ssd's als cache devices was zo gedaan:

Namen van je devices terugvinden:

code:

format

Pool maken met naampje 'tank' en aangepaste zpool binary om 4K sectorgrootte te kunnen configuren (zie http://wiki.openindiana.o...age.action?pageId=4883847 )

code:

./zpool create tank block-size 4096 mirror c2t5000C50037A08128d0 c2t5000C50037AA751Fd0 mirror c2t5000C50037AACC25d0 c2t5000C50037AB21E0d0 mirror c2t5000C50037B4CD12d0 c2t5000C50037C1A26Dd0 mirror c2t5000C50037C3B7D0d0 c2t5000C50037C37CB1d0 mirror c2t5000C50037C37DC3d0 c2t5000C50037C38A34d0 mirror c2t5000C50037C28658d0 c2t5000C50037876087d0

Cache toevoegen:

code:

zpool add tank cache c3d0 c4d0 c4d1 c6d0 c6d1

Een zfs volume aanmaken en die via iscsi exporteren maken was ook makkelijk te doen.

Comstar service aanzettten:

code:

svcadm enable svc:/system/stmf:default

ZFS volume van 250GB aanmaken in pool:

code:

zfs create -V 250G tank/testvolume

Logical unit creeëren voor ZFS-volume:

code:

sbdadm create-lu /dev/zvol/rdsk/tank/testvolume

List van id logical unit:

code:

sbdadm list-lu

Mappen van logical unit:

code:

stmfadm add-view 600144f00800271b51c04b7a6dc70001

iscsi target creeëren:

code:

itadm create-target

List targets:

code:

itadm list-target

Static discovery configureren:

code:

devfsadm -i iscsi

Zie voor meer uitleg http://thegreyblog.blogsp...-solaris-comstar-and.html .

Om hiermee te verbinden in Windows 7 schakel je de iscsi initiator in via Control Panel > System and Security > Administrative Tools > iSCSI Initiator waar je bij Target het ip van je zfs machine opgeeft. Als het goed is vindt hij dan je Comstar iscsi target terug en heb je een block level device erbij gekregen in disk management.

Eerste test in AS-SSD levert lang niet slechte prestaties op via gigabit ethernet. Sequentieel schrijven was initieel ~100MB/s maar kakte daarna in naar 56,6MB/s:



Ik ga er nu even onze standaard trace-based benchmarks overheen gooien.

Fibre channel configureren lijkt ook goed te doen maar heb ik alleen niet kunnen testen omdat ik geen fysieke toegang meer heb tot ons testlab om wat kabeltjes aan te sluiten en een fc-adapter in de ons storage testsysteem te pluggen om als fibre channel initiator te dienen. Wat me niet duidelijk is hoe ALUA multipath I/O aangezet moet worden. Als ik via stmfadm list-state de status van de scsi target service opvraag staat de ALUA status op disabled. Ik kan nergens vinden hoe dat aan moet.

Een goede tutorial over het bouwen van een fc target vind je hier: http://blog.allanglesit.c...ng-fibre-channel-targets/ .

Lokaal haal ik met bonnie de volgende resultaten:

Sequential output (write) - block: 443MB/s
Sequential input (read) - block: 698MB/s
Random seeks: 5675,2/s
Sequential create: 27408/s
Random create: 24753/s

[ Voor 3% gewijzigd door Femme op 17-12-2011 00:36 ]

[Q]

Leuke eerste test. De array is dus eigenlijk een RAID 10 van 12 disks. Dus je stripe gaat over 6 disks. Theoretisch haal je met 150mb/s per disk dan 900mb/s maar als je 115 mb/s per disk haalt, super.

Wel vreemd dat de performance inkakt over gigabit.