thr3ads.net - Gluster users - [Gluster-users] Re : HA +unify design with multiply server with multiple client [Jan 2009]

If this information is useful, please help other people find it:
Share via:

mohan L

2009-Jan-23 13:41 UTC

[Gluster-users] Re : HA +unify design with multiply server with multiple client

Dear All ,

I am trying to design high available and cluster set up for my benchmarking
.Today I read  some design information available in GlusterFS home page .


http://www.gluster.org/docs/index.php/Simple_High_Availability_Storage_with_GlusterFS_2.0#Larger_storage_using_Unify_.2B_AFR

  It is configured using 6 server single client .server 1 and server 2 has
two  directory /export and /export-ns .

volume brick1
 type protocol/client
 option transport-type tcp
 option remote-host 192.168.1.1      # IP address of the remote brick
 option remote-subvolume brick        # name of the remote volume
end-volume
>From this I understand thatIt will mount the server1(192.168.1.1) exported directory  to client
machine mount point

volume brick2
 type protocol/client
 option transport-type tcp
 option remote-host 192.168.1.2
 option remote-subvolume brick
end-volume

It will mount the server2 (192.168.1.2) exported directory  to client
machine mount point




volume brick3
 type protocol/client
 option transport-type tcp
 option remote-host 192.168.1.3
 option remote-subvolume brick
end-volume

It will mount the server3 (192.168.1.3) exported directory  to client
machine mount point

volume brick4
 type protocol/client
 option transport-type tcp
 option remote-host 192.168.1.4
 option remote-subvolume brick
end-volume

It will mount the server4 (192.168.1.4) exported directory  to client
machine mount point

volume brick5
 type protocol/client
 option transport-type tcp
 option remote-host 192.168.1.5
 option remote-subvolume brick
end-volume

It will mount the server5 (192.168.1.5) exported directory  to client
machine mount point

volume brick6
 type protocol/client
 option transport-type tcp
 option remote-host 192.168.1.6
 option remote-subvolume brick
end-volume

It will mount the server6 (192.168.1.6) exported directory  to client
machine mount point

volume brick-ns1
 type protocol/client
 option transport-type tcp
 option remote-host 192.168.1.1
 option remote-subvolume brick-ns  *# Note the different remote volume name.*
end-volume

It will mount the server1(192.168.1.1) exported directory (/home/export-ns/
) to client machine mount point


volume brick-ns2
 type protocol/client
 option transport-type tcp
 option remote-host 192.168.1.2
 option remote-subvolume brick-ns  *# Note the different remote volume name.*
end-volume

It will mount the server2(192.168.1.2) exported directory (/home/export-ns/
) to client machine mount point



volume afr1
 type cluster/afr
 subvolumes brick1 brick4
end-volume

Here  brick1 replicates all files to brick4 ,Is it correct?

volume afr2
 type cluster/afr
 subvolumes brick2 brick5
end-volume

volume afr3
 type cluster/afr
 subvolumes brick3 brick6
end-volume

volume afr-ns
 type cluster/afr
 subvolumes brick-ns1 brick-ns2
end-volume

Here the namespace information are replicating .Is it correc?

volume unify
 type cluster/unify
 option namespace afr-ns
 option scheduler rr
 subvolumes afr1 afr2 afr3
end-volume

what actuly unify does here?
what is the meaning of namespace in GlusterFS?
what about storage scalibality in this design? both server and client. can
you please give one example ?
how can do HA +unify design with multiply server with multiple client?for
example 8 server two client .


 any one please help me to understand those and correct me .

Thanks for your time
 L. Mohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20090123/ca6c632b/attachment.html>

Raghavendra G

2009-Jan-27 05:41 UTC

head link

[Gluster-users] [Gluster-devel] Re : HA +unify design with multiply server with multiple client

Hi Mohan,
please find the inlined comments.

2009/1/23 mohan L <l.mohanphy at gmail.com>
> Dear All ,
>
> I am trying to design high available and cluster set up for my benchmarking
> .Today I read  some design information available in GlusterFS home page .
>
>
>
>
http://www.gluster.org/docs/index.php/Simple_High_Availability_Storage_with_GlusterFS_2.0#Larger_storage_using_Unify_.2B_AFR
>
>   It is configured using 6 server single client .server 1 and server 2 has
> two  directory /export and /export-ns .
>
> volume brick1
>  type protocol/client
>  option transport-type tcp
>  option remote-host 192.168.1.1      # IP address of the remote brick
>
>  option remote-subvolume brick        # name of the remote volume
> end-volume
>
> From this I understand that
> It will mount the server1(192.168.1.1) exported directory  to client
machine mount point
>
> volume brick2
>
>  type protocol/client
>  option transport-type tcp
>  option remote-host 192.168.1.2
>  option remote-subvolume brick
> end-volume
>
> It will mount the server2 (192.168.1.2) exported directory  to client
machine mount point
>
>
>
>
> volume brick3
>  type protocol/client
>  option transport-type tcp
>  option remote-host 192.168.1.3
>  option remote-subvolume brick
> end-volume
>
> It will mount the server3 (192.168.1.3) exported directory  to client
machine mount point
>
> volume brick4
>  type protocol/client
>  option transport-type tcp
>  option remote-host 192.168.1.4
>  option remote-subvolume brick
> end-volume
>
> It will mount the server4 (192.168.1.4) exported directory  to client
machine mount point
>
> volume brick5
>  type protocol/client
>  option transport-type tcp
>  option remote-host 192.168.1.5
>  option remote-subvolume brick
> end-volume
>
> It will mount the server5 (192.168.1.5) exported directory  to client
machine mount point
>
> volume brick6
>  type protocol/client
>  option transport-type tcp
>  option remote-host 192.168.1.6
>  option remote-subvolume brick
> end-volume
>
> It will mount the server6 (192.168.1.6) exported directory  to client
machine mount point
>
> volume brick-ns1
>  type protocol/client
>  option transport-type tcp
>  option remote-host 192.168.1.1
>  option remote-subvolume brick-ns  *# Note the different remote volume
name.*
> end-volume
>
> It will mount the server1(192.168.1.1) exported directory (/home/export-ns/
>
> ) to client machine mount point
>
>
> volume brick-ns2
>  type protocol/client
>  option transport-type tcp
>  option remote-host 192.168.1.2
>  option remote-subvolume brick-ns  *# Note the different remote volume
name.*
>
> end-volume
>
> It will mount the server2(192.168.1.2) exported directory (/home/export-ns/
> ) to client machine mount point
>
>
>
> volume afr1
>  type cluster/afr
>  subvolumes brick1 brick4
> end-volume
>
> Here  brick1 replicates all files to brick4 ,Is it correct?
>
>yes.

>
>
> volume afr2
>  type cluster/afr
>  subvolumes brick2 brick5
> end-volume
>
> volume afr3
>  type cluster/afr
>  subvolumes brick3 brick6
> end-volume
>
> volume afr-ns
>  type cluster/afr
>  subvolumes brick-ns1 brick-ns2
> end-volume
>
> Here the namespace information are replicating .Is it correc?
>
> volume unify
>  type cluster/unify
>  option namespace afr-ns
>
>  option scheduler rr
>  subvolumes afr1 afr2 afr3
> end-volume
>
> what actuly unify does here?

unify is used to aggregate the contents of afr1, afr2 and afr3. Say
following is the list of files on afr1, afr2 and afr3,

afr1: file-1
afr2: file-2
afr3: file-3

then using unify to aggregate all the three afr subvolumes results in a
filesystem containing all the three files.

unify (of afr1, afr2, afr3): file-1, file-2, file-3.

> what is the meaning of namespace in GlusterFS?

namespace is just a cache, which holds the directory tree of unify. Please
note that the files contained in this directory tree are of zero byte sized.


> what about storage scalibality in this design? both server and client. can
> you please give one example ?

only bottleneck in scalability is the namespace node. It should be able to
hold the entire directory structure of unify (with zero byte sized files).
Other than that, a new node can be added just by changing the configuration
file and remounting glusterfs.

>
> how can do HA +unify design with multiply server with multiple client?for
> example 8 server two client .

If replication is not needed, each of the client can have unify of all the
volumes exported by servers.

volume unify
  type cluster/unify
  subvolumes ha1, ha2..... ha8.
end-volume

and ha1, ha2.. ha8  provide High availability using multiple links to the
same server.

say,
volume ha1
  type cluster/ha
  subvolumes client-1a, client-1b
end-volume

where client-1a and client-1b are two different links to server1.

regards,

>
>
>  any one please help me to understand those and correct me .
>
> Thanks for your time
>  L. Mohan
>
>
>
>
>
>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>

-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20090127/585b2956/attachment.html>

Keith Freedman

2009-Jan-27 11:34 UTC

head link

[Gluster-users] [Gluster-devel] Re : HA +unify design with multiply server with multiple client

At 09:41 PM 1/26/2009, Raghavendra G wrote:>namespace is just a cache, which holds the directory tree of unify. 
>Please note that the files contained in this directory tree are of 
>zero byte sized.
>
>what about storage scalibality in this design? both server and 
>client. can you please give one example ?
>
>only bottleneck in scalability is the namespace node. It should be 
>able to hold the entire directory structure of unify (with zero byte 
>sized files). Other than that, a new node can be added just by 
>changing the configuration file and remounting glusterfs.
so, it would be advisable for people to use a filesystem with a very 
small blocksize and a large number of inodes (or one that supports 
dynamic inode allocation) presumably?
is this documented as a suggestion anywhere?

Raghavendra G

2009-Jan-27 17:12 UTC

head link

[Gluster-users] [Gluster-devel] Re : HA +unify design with multiply server with multiple client

Hi Keith,
please find the inlined comments.

On Tue, Jan 27, 2009 at 3:34 PM, Keith Freedman <freedman at
freeformit.com>wrote:
> At 09:41 PM 1/26/2009, Raghavendra G wrote:
> >namespace is just a cache, which holds the directory tree of unify.
> >Please note that the files contained in this directory tree are of
> >zero byte sized.
> >
> >what about storage scalibality in this design? both server and
> >client. can you please give one example ?
> >
> >only bottleneck in scalability is the namespace node. It should be
> >able to hold the entire directory structure of unify (with zero byte
> >sized files). Other than that, a new node can be added just by
> >changing the configuration file and remounting glusterfs.
>
> so, it would be advisable for people to use a filesystem with a very
> small blocksize and a large number of inodes (or one that supports
> dynamic inode allocation) presumably?

yes.

>
> is this documented as a suggestion anywhere?

Its mentioned in the following FAQ.
http://gluster.org/docs/index.php/Understanding_Unify_Translator#Namespace_FAQ

>
>
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
>


-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20090127/3826072c/attachment.html>

Gluster users - Jan 2009 - Re : HA +unify design with multiply server with multiple client

[Gluster-users] Re : HA +unify design with multiply server with multiple client

[Gluster-users] [Gluster-devel] Re : HA +unify design with multiply server with multiple client

[Gluster-users] [Gluster-devel] Re : HA +unify design with multiply server with multiple client

[Gluster-users] [Gluster-devel] Re : HA +unify design with multiply server with multiple client