Simple High Availability Storage with GlusterFS 1.3

From GlusterDocumentation

Jump to: navigation, search

Contents

[edit]

Introduction

High Availability is achieved in GlusterFS using AFR (Automatic File Replication) translator. Using this translator in the GlusterFS volume spec file will enable one to store the data redundantly. By using AFR translator on the client side, this goal is achieved very easily.

[edit]

Overview

TODO: Get the picture ready

[edit]

Configuration

[edit]

Simple setup ( Only AFR )

[edit]

Server spec file 

volume brick
 type storage/posix 
 option directory /home/export/
end-volume

### Add network serving capability to above brick.
volume server
 type protocol/server
 option transport-type tcp/server     # For TCP/IP transport
 subvolumes brick
 option auth.ip.brick.allow 192.168.1.* # Allow access to "brick" volume
end-volume
[edit]

Client spec file 

### Add client feature and attach to remote subvolume of server1
volume brick1
 type protocol/client
 option transport-type tcp/client     # for TCP/IP transport
 option remote-host 192.168.1.1      # IP address of the remote brick
 option remote-subvolume brick        # name of the remote volume
end-volume

### Add client feature and attach to remote subvolume of server2
volume brick2
 type protocol/client
 option transport-type tcp/client     # for TCP/IP transport
 option remote-host 192.168.1.2      # IP address of the remote brick
 option remote-subvolume brick        # name of the remote volume
end-volume

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

volume afr
 type cluster/afr
 subvolumes brick1 brick2 brick3
end-volume
[edit]

Brief Overview of setup

In this setup, there are 3 servers, (with IP, 192.168.1.1, 192.168.1.2, and 192.168.1.3) and any clients from the same network (ie, 192.168.1.x) can connect to them using the client spec file. After mounting GlusterFS using these spec file, any file written to the mountpoint will be stored on each of three storage nodes. Even if one of the node goes down, data will be available at the mountpoint, as it can read/write to the other two storage nodes.

[edit]

Larger storage using Unify + AFR

[edit]

Server spec file 

volume brick
 type storage/posix 
 option directory /home/export/
end-volume

volume brick-ns
 type storage/posix
 option directory /home/export-ns/
end-volume

### Add network serving capability to above brick.
volume server
 type protocol/server
 option transport-type tcp/server     # For TCP/IP transport
 subvolumes brick brick-ns
 option auth.ip.brick.allow 192.168.1.* # Allow access to "brick" volume
 option auth.ip.brick-ns.allow 192.168.1.* # Allow access to "brick-ns" volume
end-volume
[edit]

Client spec file 

volume brick1
 type protocol/client
 option transport-type tcp/client     # for TCP/IP transport
 option remote-host 192.168.1.1      # IP address of the remote brick
 option remote-subvolume brick        # name of the remote volume
end-volume

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

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

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

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

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

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

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

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

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

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

Brief Overview of setup

In the above setup, servers are running in nodes 192.168.1.[1-6], and client needs to be in the same network. Here, Each file in the GlusterFS mountpoint is stored at two different nodes. Hence even if one of the node goes down, the data is available.

[edit]

FAQ

Q1. How to specify how many number of copies of a file to be kept redundantly to AFR translator.

A1. Currently AFR uses number of subvolumes as the number of copies a file is replicated.

Retrieved from "http://www.gluster.org/docs/index.php/Simple_High_Availability_Storage_with_GlusterFS_1.3"
Personal tools