Gluster new user docs

From GlusterFS Documentation
Jump to navigationJump to search
Home

GlusterFS Concepts[edit | edit source]


GlusterFS is a powerful network/cluster filesystem written in user space which uses FUSE to hook itself with VFS layer. GlusterFS takes a layered approach to the file system, where features are added/removed as per the requirement. Though GlusterFS is a File System, it uses already tried and tested disk file systems like ext3, ext4, xfs, etc. to store the data. It can easily scale up to petabytes of storage which is available to user under a single mount point.

Terms[edit | edit source]

Brick
The brick is a storage filesystem that has been assigned to a volume.

Client
The machine which mounts a volume (this may also be the server).

Server
The machine (virtual or bare metal) which holds the actual filesystem in which data will bw stored.

Subvolume
A brick after being processor by atleast one translator.

Volume
The final share after it passes through all the translators.

Translators[edit | edit source]

A translator connects to one or more subvolumes, does something with them, and offers a subvolume connection.

Translator.png

The brick's first translator (or last, depending on what direction data is flowing) is the storage/posix translator that manages the direct filesystem interface for the rest of the translators.

First-translator.png

The configuration of translators (since GlusterFS 3.1) is managed through the gluster command line interface (cli), so you don't need to know in what order to graph the translators together.

All the translators hooked together to perform a function is called a graph. A complete brick graph might look like this:

Graph.png

Distribute[edit | edit source]


Distribute takes a list of subvolumes and distributes files across them, effectively making one single larger storage volume from a series of smaller ones.

Distribute.png

With 4 files

  • file1.txt
  • file2.txt
  • file3.txt
  • file4.txt



Each file may (probably would) be written to a different server using the distribute translator.

file1.txt server3
file2.txt server4
file3.txt server1
file4.txt server2

The server that the files are written to is calculated by hashing the filename. If the filename changes, a pointer file is written to the server that the new hash code would point to, telling the distribute translator which server the file is actually on.


Plus and Minus[edit | edit source]

Disadvantages

  • If you lose a single server, you lose access to all the files that are hosted on that server. This is why distribute is typically graphed to the replicate translator.
  • If your file is larger than the subvolume, writing your file will fail.
  • If the file is not where the hash code calculates to, an extra lookup operation must be performed, adding slightly to latency.


Advantages

  • The more servers you add, the better this scales in terms of random file access. As long as clients aren't all retrieving the same file, their access should be spread pretty evenly across all the servers.
  • Increasing volume can be done by adding a new server. Adding servers can be done on-the-fly (Since 3.1.0).

Replicate[edit | edit source]


Replicate is used for providing redundancy to both storage and generally to availability.

Stripe[edit | edit source]


Stripes data across bricks in the volume. For best results, you should use striped volumes only in high concurrency environments accessing very large files.

Home