Solaris
2008-Oct-09 20:09 UTC
[zfs-discuss] Strategies to avoid single point of failure w/ X45x0 Servers?
I have been leading the charge in my IT department to evaluate the Sun Fire X45x0 as a commodity storage platform, in order to leverage capacity and cost against our current NAS solution which is backed by EMC Fiberchannel SAN. For our corporate environments, it would seem like a single machine would supply more than triple our current usable capacity on our NAS, and the cost is significantly less per GB. I am also working to prove the multi-protocol shared storage capabilities of the Thumper significantly out perform those of our current solution (which is notoriously bad from the end user perspective). The EMC solution is completely redundant with no single point of failure. What are some good strategies for providing a Thumper solution with no single point of failure? The storage folks are poo-poo''ing this concept because of the chances for an Operating System failure... I''d like to come up with some reasonable methods to put them in their place :)
Tim
2008-Oct-09 20:27 UTC
[zfs-discuss] Strategies to avoid single point of failure w/ X45x0 Servers?
On Thu, Oct 9, 2008 at 3:09 PM, Solaris <solaris at alderhost.net> wrote:> I have been leading the charge in my IT department to evaluate the Sun > Fire X45x0 as a commodity storage platform, in order to leverage > capacity and cost against our current NAS solution which is backed by > EMC Fiberchannel SAN. For our corporate environments, it would seem > like a single machine would supply more than triple our current usable > capacity on our NAS, and the cost is significantly less per GB. I am > also working to prove the multi-protocol shared storage capabilities > of the Thumper significantly out perform those of our current solution > (which is notoriously bad from the end user perspective). > > The EMC solution is completely redundant with no single point of > failure. What are some good strategies for providing a Thumper > solution with no single point of failure? > > The storage folks are poo-poo''ing this concept because of the chances > for an Operating System failure... I''d like to come up with some > reasonable methods to put them in their place :) >Unless you''re taking about buying multiple thumpers and mirroring them, there are none. The motherboard is a single point of failure. --Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20081009/872dfea2/attachment.html>
Glaser, David
2008-Oct-09 20:30 UTC
[zfs-discuss] Strategies to avoid single point of failure w/ X45x0 Servers?
As shipped, there our x4500 have 8 raidz pools with 6 disks each in them. If spaced right, you can loose 6(?) disks without the pool dying. The root disk is mirrored, so if one dies it''s not the end of the world. With the exception that grub is thoroughly fraked up in that if the 0 disk dies, you have to manually make the darn thing boot. You can''t hot swap CPU or memory, but you can swap drives, fans, network links, and power supplies. With the rest of the hardware redundancy built in, they have been working pretty well for us here. We did have some issues with a failure of the machine (software related) but with a decent support contract, you should be ok. Our windows group purchased their BlueArc san and spent 100k for 15TB (raw)... I spent 50K for 33TB (useable)... David David Glaser Systems Administrator LSA Information Technology University of Michigan -----Original Message----- From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-bounces at opensolaris.org] On Behalf Of Solaris Sent: Thursday, October 09, 2008 4:09 PM To: zfs-discuss at opensolaris.org Subject: [zfs-discuss] Strategies to avoid single point of failure w/ X45x0 Servers? I have been leading the charge in my IT department to evaluate the Sun Fire X45x0 as a commodity storage platform, in order to leverage capacity and cost against our current NAS solution which is backed by EMC Fiberchannel SAN. For our corporate environments, it would seem like a single machine would supply more than triple our current usable capacity on our NAS, and the cost is significantly less per GB. I am also working to prove the multi-protocol shared storage capabilities of the Thumper significantly out perform those of our current solution (which is notoriously bad from the end user perspective). The EMC solution is completely redundant with no single point of failure. What are some good strategies for providing a Thumper solution with no single point of failure? The storage folks are poo-poo''ing this concept because of the chances for an Operating System failure... I''d like to come up with some reasonable methods to put them in their place :) _______________________________________________ zfs-discuss mailing list zfs-discuss at opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Solaris
2008-Oct-09 20:36 UTC
[zfs-discuss] Strategies to avoid single point of failure w/ X45x0 Servers?
Perhaps a better solution would be to front a J4500 with a pair of X4100s with Sun Cluster? Hrrm... On Thu, Oct 9, 2008 at 4:30 PM, Glaser, David <dsglaser at umich.edu> wrote:> As shipped, there our x4500 have 8 raidz pools with 6 disks each in them. If spaced right, you can loose 6(?) disks without the pool dying. The root disk is mirrored, so if one dies it''s not the end of the world. With the exception that grub is thoroughly fraked up in that if the 0 disk dies, you have to manually make the darn thing boot. You can''t hot swap CPU or memory, but you can swap drives, fans, network links, and power supplies. > > With the rest of the hardware redundancy built in, they have been working pretty well for us here. We did have some issues with a failure of the machine (software related) but with a decent support contract, you should be ok. > > Our windows group purchased their BlueArc san and spent 100k for 15TB (raw)... I spent 50K for 33TB (useable)... > > > David > > > David Glaser > Systems Administrator > LSA Information Technology > University of Michigan > > -----Original Message----- > From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-bounces at opensolaris.org] On Behalf Of Solaris > Sent: Thursday, October 09, 2008 4:09 PM > To: zfs-discuss at opensolaris.org > Subject: [zfs-discuss] Strategies to avoid single point of failure w/ X45x0 Servers? > > I have been leading the charge in my IT department to evaluate the Sun > Fire X45x0 as a commodity storage platform, in order to leverage > capacity and cost against our current NAS solution which is backed by > EMC Fiberchannel SAN. For our corporate environments, it would seem > like a single machine would supply more than triple our current usable > capacity on our NAS, and the cost is significantly less per GB. I am > also working to prove the multi-protocol shared storage capabilities > of the Thumper significantly out perform those of our current solution > (which is notoriously bad from the end user perspective). > > The EMC solution is completely redundant with no single point of > failure. What are some good strategies for providing a Thumper > solution with no single point of failure? > > The storage folks are poo-poo''ing this concept because of the chances > for an Operating System failure... I''d like to come up with some > reasonable methods to put them in their place :) > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >-- Ignorance: America''s most abundant and costly commodity.
Chris Greer
2008-Oct-10 04:51 UTC
[zfs-discuss] Strategies to avoid single point of failure w/ X45x0 Servers?
If you are having touble booting to the mirrored drive, the following is what we had to do to correctly boot off the mirrored drive in a Thumper mirrored with disksuite. The root drive is c5t0d0 and the mirror is c5t4d0. The BIOS will try those 2 drives. Just a note, if it ever switches to c5t4d0 as the primary boot device, the BIOS will not swap back autoamtically. You will have to change this back by hand in the BIOS. Mostly likely you''ll find this out on your next OS upgrade when you upgrade c5t0d0 only to still be booting off c5t4d0. The vtoc.out file was created with prtvtoc on the primary root drive. and the partitions were added to SVM and synced one by one in a for loop. MIRROR=c5t4d0 echo "y" | /usr/sbin/fdisk -B /dev/rdsk/${MIRROR}s2 echo "5" | /usr/sbin/fdisk -b /usr/lib/fs/ufs/mboot /dev/rdsk/${MIRROR}p0 /usr/sbin/fmthard -s /tmp/disk-vtoc.out /dev/rdsk/${MIRROR}s2 /sbin/installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/${MIRROR}s0 -- This message posted from opensolaris.org
Daryl Doami
2008-Oct-10 04:56 UTC
[zfs-discuss] Strategies to avoid single point of failure w/ X45x0 Servers?
Hi, Maybe this might be an option too? http://blogs.sun.com/storage/entry/mike_shapiro_and_steve_o -------- Original Message -------- Subject: [zfs-discuss] Strategies to avoid single point of failure w/ X45x0 Servers? From: Solaris <solaris at alderhost.net> To: zfs-discuss at opensolaris.org Date: Thu Oct 9 13:09:28 2008> I have been leading the charge in my IT department to evaluate the Sun > Fire X45x0 as a commodity storage platform, in order to leverage > capacity and cost against our current NAS solution which is backed by > EMC Fiberchannel SAN. For our corporate environments, it would seem > like a single machine would supply more than triple our current usable > capacity on our NAS, and the cost is significantly less per GB. I am > also working to prove the multi-protocol shared storage capabilities > of the Thumper significantly out perform those of our current solution > (which is notoriously bad from the end user perspective). > > The EMC solution is completely redundant with no single point of > failure. What are some good strategies for providing a Thumper > solution with no single point of failure? > > The storage folks are poo-poo''ing this concept because of the chances > for an Operating System failure... I''d like to come up with some > reasonable methods to put them in their place :) > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
Ralf Ramge
2008-Oct-10 06:59 UTC
[zfs-discuss] Strategies to avoid single point of failure w/ X45x0 Servers?
Solaris wrote:> Perhaps a better solution would be to front a J4500 with a pair of > X4100s with Sun Cluster? Hrrm...That''s a way better solution, since you can then build a clustered solution for basically the same price. u should also think about using 2x J4400 instead of 1x J4500 to eliminate the storage as a SPoF, too. -- Ralf Ramge Senior Solaris Administrator, SCNA, SCSA Tel. +49-721-91374-3963 ralf.ramge at webde.de - http://web.de/ 1&1 Internet AG Brauerstra?e 48 76135 Karlsruhe Amtsgericht Montabaur HRB 6484 Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss Aufsichtsratsvorsitzender: Michael Scheeren