QuicksearchDisclaimerThe individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.
|
Raisins, Storage, Solaris and the X4275Friday, April 17. 2009Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Beeindruckende Datenmenge, aber zuviel SATA.
Angst um deine Daten musst du bei jeder Art rotierendem Rost haben. Egal ob du nun SAS oder SATA hast. Die oben beschriebene Loesung arbeitet mit zwei uebereinanderliegenden ZFS-Checksummen.
Ausreichend grosse Caches vorausgesetzt, kannst du die Platten auch locker in ihrem Usagepattern halten (geht auch in richtig gross, aber dazu kann ich noch nicht so viel sagen ... "upcoming products"). In ihren Usagepattern sind SAS und SATA gleich zuverlaessig, die meisten Horrorgeschichten kommen von Leuten, die versuchen SATA disks mit Schwerlastdatenbanken zu betreibe. Das kann nich gutgehen. Ansonsten in die Headnodes einfach reihenweise SSD reinstecken (vielleicht 16x groessere SSD) per Headnode. Mit Hybrid Storage Pools, SSD muss man sich von einigen Gedankengaengen verabschieden. Shit ... du bringst mich da gerade auf eine Idee fuer Caches .... ich muss da mal drueber nachdenken ... Danke für den Gedankenanstoss ....
Hi Joerg,
Interesting post because it at least attempts to offer a solution for the pockets of unused local storage we all have in our environments. More often than not the issue is not whether there is storage available but rather is it available where it's needed and with the profile (RAID0, 1, 5) to match a particular workload. This dilemma is what gave rise to centralized storage in SANs and the promise of better storage utilization. With Sun racking up points in the industry for opening up and commoditizing Enterprise storage, another potentially customer-pleasing (and revenue-producing) "killer-app" would be tools to enable customers to aggregate the local storage trapped in individual hosts and present it all in a unified name space. Tall order, I'm sure but it seems as though many of the building blocks are already in place. Maybe if it were possible to drop a slimmed-down FISHWorks VSA in an VirtualBox instance on each host (as Storage Node Agent) to provision and cluster each host's free space. Some other tool/protocol could unify the parts and present one namespace to acces the SAN-free storage "grid. Seem like some of the concepts used in projects like Terracotta NAM and unified namespace in products like ISILON OneFS would make RAISIN a viable alternative to expensive SANs.
Na ja, als Horrorgeschichten würde ich das nicht bezeichnen. Es ist nun mal so, dass SATA Platten nicht für den gleichen Duty-Cycle ausgelegt sind, wie SAS oder FC Platten. Die mögen es einfach nicht, wenn man sie ständig und heftig mit random IO ärgert. In wie weit man das über Checksummen und Caches wegbügeln kann, kann man sicherlich streiten. SATA ist okay für Archive, B2D, noch ganz so hochlastigen IO. Ich habe selber Anlagen mit wo 500 TB am Stück stehen - aber halt Archiv, nix online oder so.
|
+1The LKSF bookThe book with the consolidated Less known Solaris Tutorials is available for download here
Web 2.0Contact
Networking xing.com My photos Buttons![]() This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Germany License
![]() ![]() ![]() Blog AdministrationDonateOkay, okay ... as several people have asked for it ... but you know my opinion.
|