[Ocfs2-users] Ocfs2-users Digest, Vol 105, Issue 9

David Johle djohle at industrialinfo.com
Mon Sep 17 10:30:52 PDT 2012


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





More information about the Ocfs2-users mailing list