Any respectable SAN will have some, if not several, layers of hardware redundancy. RAID for the disks, multiple enclosures, controllers, redundant NICs, etc. You can then connect your SAN to multiple ethernet switches in such a way that there is no single point of failure due to a network cable or switch failure. At the server level, use multiple NICs attached to different switches, and then use multipathing to utilize the bandwidth of both network ports as well as mitigate the effects of a NIC or cable failure. So to recap... Disks - RAID Enclosure and/or controllers NICs on SAN Switches & cabling NICs on server Multipathed block devices And of course, OCFS2 That takes care all the way from the disks on up to your filesystem layer. After that it really depends on the applications you run and how they are designed for handling failures such as an entire server crashing. At 02:00 PM 9/15/2012, ocfs2-users-request at oss.oracle.com wrote:>Message: 1 >Date: Sat, 15 Sep 2012 11:32:01 -0700 (PDT) >From: Eric <epretorious at yahoo.com> >Subject: Re: [Ocfs2-users] HA-OCFS2? >To: "ocfs2-users at oss.oracle.com" <ocfs2-users at oss.oracle.com> >Message-ID: > <1347733921.89022.YahooMailNeo at web121702.mail.ne1.yahoo.com> >Content-Type: text/plain; charset="iso-8859-1" > >Thanks, Lars: > >Using cLVM2 for the back-end sounds like a strong possibility. How >would you recommend making the SAN highly-available to the OCFS2 >cluster (i.e., the SAN clients)? Is this type of scenario something >that is already engineered into the SUSE Linux Enterprise High >Availability Extension? > >Eric Pretorious >Truckee, CA