From: allan <allane@spinn.net>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM + raid + san
Date: Sat, 06 Nov 2010 22:03:54 -0600 [thread overview]
Message-ID: <4CD6252A.9040003@spinn.net> (raw)
In-Reply-To: <4CD5F804.3040906@cfl.rr.com>
Have you considered using mdadm for the RAID configuration and lvm to carve it up?
Phillip Susi wrote:
> My understanding of a SAN is where you get a few drive enclosures and a
> few servers and plug them all into a sas expander so all of the servers
> can see all of the disks. You seem to be talking about having all of
> the disks on one server that then serves them over ethernet with iscsi.
> I wouldn't want to do that because it adds a good deal of overhead to
> the disk access and introduces a single point of failure.
>
> I'd rather just use LVM to manage all of the disks as part of a single
> volume group so you can immediately transfer a lv from one server to
> another, but I can't work out how to still manage to get raid without
> having lvm do it with the dm-raid5 support.
>
> On 11/05/2010 12:39 AM, Stuart D. Gathman wrote:
>> I would run LVM on the SAN server, exporting LVs as SAN units, and
>> each host
>> would get a virtual SAN disk to do with as it pleased, including running
>> LVM on it. Then you don't have to deal with locking issues for a shared
>> volume group. If your SAN server is embedded, it must already have
>> some sort
>> of management interface to parcel out disk space as virtual disks.
>> If you don't like its interface, then consider replacing it with a
>> general purpose host running LVM as described above. That said, many
>> do use shared volume groups with no problem.
>>
>> Generally, your SAN (whether embedded or a dedicated general purpose
>> host)
>> already has the raid built in. The exported virtual disks are raid
>> reliable. If not, replace the SAN. The whole point of SAN is to not
>> worry about physical disks anymore on the client systems. If you had
>> multiple
>> SANs on separate physical LANs, you could stripe them for super speed,
>> but
>> otherwise raid is already built in. And you can bond multiple 1000BT
>> interfaces with a gigabit switch to get really fast transfer from
>> the SAN anyway.
>>
>> If the SAN server is a general purpose host, I would run raid10, or
>> linux md
>> extensions to it that get most of the benefits with fewer disks:
>>
>> http://en.wikipedia.org/wiki/Non-standard_RAID_levels
>>
>> raid5 has the read/modify/rewrite problem.
>>
>> I would not use the device-mapper raid, as you note.
>>
>> Caveat: I've never actually setup a SAN, just used them.
>>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
>
next prev parent reply other threads:[~2010-11-07 4:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-05 1:26 [linux-lvm] LVM + raid + san Phillip Susi
2010-11-05 4:39 ` Stuart D. Gathman
2010-11-07 0:51 ` Phillip Susi
2010-11-07 3:38 ` Eugene Vilensky
2010-11-07 4:03 ` allan [this message]
2010-11-07 19:55 ` Phillip Susi
2010-11-07 22:27 ` Stuart D. Gathman
2010-11-09 22:15 ` Stuart D. Gathman
2010-11-10 0:21 ` Phillip Susi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CD6252A.9040003@spinn.net \
--to=allane@spinn.net \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).