Hi Ged; At the moment ZFS is not a shared file system nor a paralell file system. However lustre integration which will take some time will provide parallel file system abilities. I am unsure if lustre at the moment supports redundancy between storage nodes (it was on the road map) But ZFS at the moment supports Sun cluster 3.2 (no paralel acccess is supported) and new upcoming SAS Jbods will let you implement cheaper ZFS cluster easly. )2 x Entry level sun server + 4 x 48 slot Jbod) <http://www.sun.com/> http://www.sun.com/emrkt/sigs/6g_top.gif Mertol Ozyoney Storage Practice - Sales Manager Sun Microsystems, TR Istanbul TR Phone +902123352200 Mobile +905339310752 Fax +902123352222 Email <mailto:Ayca.Yalcin at Sun.COM> mertol.ozyoney at Sun.COM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20071020/899a42a2/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1257 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20071020/899a42a2/attachment.gif>
To my mind ZFS has a serious deficiency for JBOD usage in a high-availability clustered environment. Namely, inability to tie spare drives to a particular storage group. Example in clustering HA setups you would would want 2 SAS JBOD units and mirror between them. In this way if a chassis goes down you are still functional. However if I have a drive dies and ZFS decides out of my 2 spare drives to use one from the opposite chassis, now I am no longer HA. I have a dependency that must be fixed immediately, or a JBOD chassis outage will bring everything down. Unless this has been fixed or there''s some hidden way I haven''t heard about. In the meanwhile we keep using units with full array controllers and building pools from LUNs. This message posted from opensolaris.org
Vincent Fox wrote:> To my mind ZFS has a serious deficiency for JBOD usage in a high-availability clustered environment. >I don''t agree.> Namely, inability to tie spare drives to a particular storage group. > > Example in clustering HA setups you would would want 2 SAS JBOD units and mirror between them. In this way if a chassis goes down you are still functional. > > However if I have a drive dies and ZFS decides out of my 2 spare drives to use one from the opposite chassis, now I am no longer HA. I have a dependency that must be fixed immediately, or a JBOD chassis outage will bring everything down. >HA environments are typically designed to accommodate single failures. While some double failures may be survivable, there are almost always cases where 2 certain failures in a sequence can cause outages. A more trivial example would be that the power fails followed by the batteries in the UPS failing. Properly managed systems and hardened data centers are the solution to such potential problems. -- richard
In our data center on CRITICAL systems we plan to survive chains of several single-type failures. The HA standards we apply to a mail-server for 30,000 people are neccessarily quite high. A fully redundant 2-node failover clustered system can survive failures of half or more of it''s systems and still operate. My server nodes are in different rows on different power systems, your example wouldn''t affect me. Ditto for arrays and SAN switches. If the active node lost power and it''s other PSU had a dead UPS, the other node in the cluster would take over. It pulls from a different circuit and UPS. The only interruption we have had on this cluster was heat-related when the AC failed and lots of systems had to be shutdown entirely. And yes this did spark discussions about further measures, we are that paranoid. Anyhow, I stand by my observation that ZFS sparing currently offers no mechanism for specifying *what* it''s a valid spare for. It''s a spare for the entire pool. I see it as entirely valid criticism that this is a capability offered by "traditional array" storage controllers which is missing. If I had a chassis in one building, and my SAN switch linked to another building and a second chassis over there, I can''t control what happens when a drive fails and a spare is called for. Or at least, I don''t see how. If you want to start an argument about what is proper HA design, we can certainly do that in another thread. This message posted from opensolaris.org
On Oct 20, 2007, at 20:23, Vincent Fox wrote:> To my mind ZFS has a serious deficiency for JBOD usage in a high- > availability clustered environment. > > Namely, inability to tie spare drives to a particular storage group. > > Example in clustering HA setups you would would want 2 SAS JBOD > units and mirror between them. In this way if a chassis goes down > you are still functional. > > However if I have a drive dies and ZFS decides out of my 2 spare > drives to use one from the opposite chassis, now I am no longer > HA. I have a dependency that must be fixed immediately, or a JBOD > chassis outage will bring everything down.did your file an RFE for this yet? in the mean time you could do this with an intermediary agent to do a replace based on the location of the failed drive .. depending on how you''re connecting, you may even have to maintain a ctd to array mapping if it''s not being picked up by the native leadville tools or hba utilities --- .je