[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [linux-lvm] Distributed LVM/filesystem/storage
- From: "Greg Freemyer" <greg freemyer gmail com>
- To: "LVM general discussion and development" <linux-lvm redhat com>, "Maximilian Wilhelm" <max rfc2324 org>
- Cc:
- Subject: Re: [linux-lvm] Distributed LVM/filesystem/storage
- Date: Mon, 2 Jun 2008 09:01:14 -0400
2008/6/1 Jan-Benedict Glaw <jbglaw lug-owl de>:
> On Sun, 2008-06-01 23:09:01 +0200, Hannes Dorbath <light theendofthetunnel de> wrote:
>> Jan-Benedict Glaw wrote:
>> > However I still fail to find a good approach. One initial idea was to
>> > export all physical volumes (partitions or full disks) vie NBD, join
>> > them all on a single machine into one VG/LV, create a filesystem and
>> > re-export that via NFS/SMB/... However, all data would need to go
>> > through the net twice. While speed isn't the most important thing here
>> > (but storage is!), that's way suboptimal.
>>
>> GlusterFS with Unify translator is exactly what you are asking for.
>>
>> http://www.gluster.org/docs/index.php/GlusterFS
>
> Already had a look at that, too. "Unify" seems to not directly
> implement any measure of redundancy. So if one Brick goes down,
> everything that was there is gone. Maybe its possible to play with the
> `mirror' translator as well, but on the first look, it seems to be
> non-trivial to accomodate for a steady loss and addition of bricks.
>
> MfG, JBG
I haven't seen Lustre mentioned in this thread. I think there is
kernel support, etc. May be worth checking out. (I have not used it.)
Quoting wikipedia http://en.wikipedia.org/wiki/Lustre_(file_system)
===
High availability
Lustre file system high availability features include a robust
failover and recovery mechanism, making server failures and reboots
transparent. Version interoperability between successive minor
versions of the Lustre software enables a server to be upgraded by
taking it offline (or failing it over to a standby server), performing
the upgrade, and restarting it, while all active jobs continue to run,
merely experiencing a delay.
Lustre MDSs are configured as an active/passive pair, while OSSs are
typically deployed in an active/active configuration that provides
redundancy without extra overhead. Often the standby MDS is the active
MDS for another Lustre file system, so no nodes are idle in the
cluster.
===
Greg
--
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf
The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]