Shared VM disk/image on gluster for redundancy?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/30/10, Jeff Darcy <jdarcy at redhat.com> wrote:

> You can get either, depending on how you define your lower-level
> replicate volumes.  If you define each to have exactly one app-node
> volume and one data-node volume, then it will replicate each file
> exactly twice no matter how it's used in higher-level nufa volumes.  You
> can add multiple storage/posix volumes per data node to gain even more
> flexibility in how you do that.  That's kind of the genius of the
> translator approach: instead of being limited to the combinations that
> are embedded in monolithic code, you can combine as many volumes on as
> many nodes in as many ways as you want and still end up with a single
> purpose-tuned filesystem for clients to use.

Just to make sure I got that correct

With the nufa volumes, a file is only written to one of the volumes
listed in its definition.
If the volume is a replicate volume, then the file is replicated on
each of the volumes listed in its definition.

e.g in this case
volume my_nufa
  type cluster/nufa
  option local-volume-name rep1
  subvolumes rep0 rep1 rep2
end-volume

A file is only found in one of rep0 rep1 or rep2. If it was on rep2,
then it would be inaccessible if rep2 fails such as network failure
cutting rep2 off.

Then when I add a rep3, gluster should automatically start putting new
files onto it.

At this point though, it seems that if I use nufa, I would have an
issue if I add a purely storage only rep3 instead of an app+storage
node. None of the servers will use it until their local volume reaches
max capacity right? :D

So if I preferred to have the load spread out more evenly, I should
then be using cluster/distribute?


[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux