gluster/glusterdocs
1
0
Fork 0
mirror of https://github.com/gluster/glusterdocs.git synced 2026-02-05 15:47:01 +01:00
Code Issues Releases Activity

Merge pull request #736 from black-dragon74/docs-install-nsntx

Browse Source 
[Install-Guide] Fixes and improvements
This commit is contained in:
Rakshitha Kamath
2022-07-01 12:55:35 +05:30
committed by GitHub
parent b8dce3a509 de7d64d9f5
commit f221022b39
9 changed files with 249 additions and 250 deletions
Download Patch File Download Diff File Expand all files Collapse all files

82
docs/Install-Guide/Common-criteria.md
View File

@@ -8,9 +8,9 @@ setting up Gluster.
Next, choose the method you want to use to set up your first cluster:
- Within a virtual machine
- To bare metal servers
- To EC2 instances in Amazon
- Within a virtual machine
- To bare metal servers
- To EC2 instances in Amazon
Finally, we will install Gluster, create a few volumes, and test using
them.
@@ -27,50 +27,50 @@ Gluster gets distributed across multiple hosts simultaneously. This
means that you can use space from any host that you have available.
Typically, XFS is recommended but it can be used with other filesystems
as well. Most commonly EXT4 is used when XFS isn’t, but you can (and
many, many people do) use another filesystem that suits you.
many, many people do) use another filesystem that suits you.
Now that we understand that, we can define a few of the common terms used in
Gluster.
- A **trusted pool** refers collectively to the hosts in a given
Gluster Cluster.
- A **node** or “server” refers to any server that is part of a
trusted pool. In general, this assumes all nodes are in the same
trusted pool.
- A **brick** is used to refer to any device (really this means
filesystem) that is being used for Gluster storage.
- An **export** refers to the mount path of the brick(s) on a given
server, for example, /export/brick1
- The term **Global Namespace** is a fancy way of saying a Gluster
volume
- A **Gluster volume** is a collection of one or more bricks (of
course, typically this is two or more). This is analogous to
/etc/exports entries for NFS.
- **GNFS** and **kNFS**. GNFS is how we refer to our inline NFS
server. kNFS stands for kernel NFS, or, as most people would say,
just plain NFS. Most often, you will want kNFS services disabled on
the Gluster nodes. Gluster NFS doesn't take any additional
configuration and works just like you would expect with NFSv3. It is
possible to configure Gluster and NFS to live in harmony if you want
to.
- A **trusted pool** refers collectively to the hosts in a given
Gluster Cluster.
- A **node** or “server” refers to any server that is part of a
trusted pool. In general, this assumes all nodes are in the same
trusted pool.
- A **brick** is used to refer to any device (really this means
filesystem) that is being used for Gluster storage.
- An **export** refers to the mount path of the brick(s) on a given
server, for example, /export/brick1
- The term **Global Namespace** is a fancy way of saying a Gluster
volume
- A **Gluster volume** is a collection of one or more bricks (of
course, typically this is two or more). This is analogous to
/etc/exports entries for NFS.
- **GNFS** and **kNFS**. GNFS is how we refer to our inline NFS
server. kNFS stands for kernel NFS, or, as most people would say,
just plain NFS. Most often, you will want kNFS services disabled on
the Gluster nodes. Gluster NFS doesn't take any additional
configuration and works just like you would expect with NFSv3. It is
possible to configure Gluster and NFS to live in harmony if you want
to.
Other notes:
- For this test, if you do not have DNS set up, you can get away with
using /etc/hosts entries for the two nodes. However, when you move
from this basic setup to using Gluster in production, correct DNS
entries (forward and reverse) and NTP are essential.
- When you install the Operating System, do not format the Gluster
storage disks! We will use specific settings with the mkfs command
later on when we set up Gluster. If you are testing with a single
disk (not recommended), make sure to carve out a free partition or
two to be used by Gluster later, so that you can format or reformat
at will during your testing.
- Firewalls are great, except when they aren’t. For storage servers,
being able to operate in a trusted environment without firewalls can
mean huge gains in performance, and is recommended. In case you absolutely
need to set up a firewall, have a look at
[Setting up clients](../Administrator-Guide/Setting-Up-Clients.md) for
information on the ports used.
- For this test, if you do not have DNS set up, you can get away with
using /etc/hosts entries for the two nodes. However, when you move
from this basic setup to using Gluster in production, correct DNS
entries (forward and reverse) and NTP are essential.
- When you install the Operating System, do not format the Gluster
storage disks! We will use specific settings with the mkfs command
later on when we set up Gluster. If you are testing with a single
disk (not recommended), make sure to carve out a free partition or
two to be used by Gluster later, so that you can format or reformat
at will during your testing.
- Firewalls are great, except when they aren’t. For storage servers,
being able to operate in a trusted environment without firewalls can
mean huge gains in performance, and is recommended. In case you absolutely
need to set up a firewall, have a look at
[Setting up clients](../Administrator-Guide/Setting-Up-Clients.md) for
information on the ports used.
Click here to [get started](../Quick-Start-Guide/Quickstart.md)

131
docs/Install-Guide/Community-Packages.md
View File

@@ -8,81 +8,78 @@ A **yes** means packages are (or will be) provided in the respective repository.
A **no** means no plans to build new updates. Existing packages will remain in the repos.
The following GlusterFS versions have reached EOL[1]: 8, 7, 6 and earlier.
| | | 10 | 9 |
|--------------|----------------|:---------:|:---------:|
|CentOS Storage SIG[2]|7 | no | yes |
| |8 | yes | yes |
| |Stream 8 | yes | yes |
| |Stream 9 | yes | yes |
| | | | |
|Fedora[3] |F34 | yes | yes¹ |
| |F35 | yes | yes¹ |
| |F36(rawhide) | yes | yes¹ |
| | | | |
|Debian[3] |Stretch/9 | no | yes |
| |Buster/10 | yes | yes |
| |Bullseye/11 | yes | yes |
| |Bookworm/12(sid)| yes | yes |
| | | | |
|Ubuntu Launchpad[4]|Xenial/16.04 | no | yes |
| |Bionic/18.04 | yes | yes |
| |Focal/20.04 | yes | yes |
| |Impish/21.10 | yes | yes |
| |Jammy/22.04 | yes | yes |
| |Kinetic/22.10 | yes | yes |
| | | | |
|OpenSUSE Build Service[5]|Leap15.2 | no | yes |
| |Leap15.3 | yes | yes |
| |Leap15.4 | yes | yes |
| |SLES12SP5 | no | yes |
| |SLES15SP2 | no | yes |
| |SLES15SP3 | yes | yes |
| |SLES15SP4 | yes | yes |
| |Tumbleweed | yes | yes |
| | | 10 | 9 |
| ------------------------- | ---------------- | :-: | :--: |
| CentOS Storage SIG[2] | 7 | no | yes |
| | 8 | yes | yes |
| | Stream 8 | yes | yes |
| | Stream 9 | yes | yes |
| | | | |
| Fedora[3] | F34 | yes | yes¹ |
| | F35 | yes | yes¹ |
| | F36(rawhide) | yes | yes¹ |
| | | | |
| Debian[3] | Stretch/9 | no | yes |
| | Buster/10 | yes | yes |
| | Bullseye/11 | yes | yes |
| | Bookworm/12(sid) | yes | yes |
| | | | |
| Ubuntu Launchpad[4] | Xenial/16.04 | no | yes |
| | Bionic/18.04 | yes | yes |
| | Focal/20.04 | yes | yes |
| | Impish/21.10 | yes | yes |
| | Jammy/22.04 | yes | yes |
| | Kinetic/22.10 | yes | yes |
| | | | |
| OpenSUSE Build Service[5] | Leap15.2 | no | yes |
| | Leap15.3 | yes | yes |
| | Leap15.4 | yes | yes |
| | SLES12SP5 | no | yes |
| | SLES15SP2 | no | yes |
| | SLES15SP3 | yes | yes |
| | SLES15SP4 | yes | yes |
| | Tumbleweed | yes | yes |
**NOTE** - We are not building Debian arm packages due to resource constraints for a while now. There will be only amd64 packages present on [download.gluster.org](https://download.gluster.org/pub/gluster/glusterfs/LATEST/)
#### Related Packages
| | | glusterfs-selinux | gdeploy | gluster-block | glusterfs-coreutils | nfs-ganesha | Samba |
|--------------|----------------|:-----------------:|:-------:|:-------------:|:-------------------:|:-----------:|:-----:|
|CentOS Storage SIG[2]|7 | yes | yes | yes | yes | yes | yes |
| |8 | yes | tbd | yes | yes | yes | yes |
| |Stream 8 | yes | tbd | yes | yes | yes | yes |
| |Stream 9 | yes | tbd | yes | yes | yes | yes |
| | | | | | | | |
|Fedora[3] |F34 | yes | yes | yes | yes | yes | ? |
| |F35 | yes | yes | yes | yes | yes | ? |
| |F36(rawhide) | yes | yes | yes | yes | yes | ? |
| | | | | | | | |
|Debian[3] |Stretch/9 | n/a | no | no | yes | yes | ? |
| |Buster/10 | n/a | no | no | yes | yes | ? |
| |Bullseye/11 | n/a | no | no | yes | yes | ? |
| |Bookworm/12(sid)| n/a | no | no | yes | yes | ? |
| | | | | | | | |
|Ubuntu Launchpad[4]|Xenial/16.04 | n/a/ | no | no | yes | yes | ? |
| |Bionic/18.04 | n/a | no | no | yes | yes | ? |
| |Focal/20.04 | n/a | no | no | yes | yes | ? |
| |Impish/21.10 | n/a | no | no | yes | yes | ? |
| |Jammy/22.04 | n/a | no | no | yes | yes | ? |
| |Kinetic/22.10 | n/a | no | no | yes | yes | ? |
| | | | | | | | |
|OpenSUSE Build Service[5]|Leap15.2| n/a | yes | yes | yes | yes | ? |
| |Leap15.3 | n/a | yes | yes | yes | yes | ? |
| |Leap15.4 | n/a | yes | yes | yes | yes | ? |
| |SLES12SP5 | n/a | yes | yes | yes | yes | ? |
| |SLES15SP2 | n/a | yes | yes | yes | yes | ? |
| |SLES15SP3 | n/a | yes | yes | yes | yes | ? |
| |SLES15SP4 | n/a | yes | yes | yes | yes | ? |
| |Tumbleweed | n/a | yes | yes | yes | yes | ? |
| | | glusterfs-selinux | gdeploy | gluster-block | glusterfs-coreutils | nfs-ganesha | Samba |
| ------------------------- | ---------------- | :---------------: | :-----: | :-----------: | :-----------------: | :---------: | :---: |
| CentOS Storage SIG[2] | 7 | yes | yes | yes | yes | yes | yes |
| | 8 | yes | tbd | yes | yes | yes | yes |
| | Stream 8 | yes | tbd | yes | yes | yes | yes |
| | Stream 9 | yes | tbd | yes | yes | yes | yes |
| | | | | | | | |
| Fedora[3] | F34 | yes | yes | yes | yes | yes | ? |
| | F35 | yes | yes | yes | yes | yes | ? |
| | F36(rawhide) | yes | yes | yes | yes | yes | ? |
| | | | | | | | |
| Debian[3] | Stretch/9 | n/a | no | no | yes | yes | ? |
| | Buster/10 | n/a | no | no | yes | yes | ? |
| | Bullseye/11 | n/a | no | no | yes | yes | ? |
| | Bookworm/12(sid) | n/a | no | no | yes | yes | ? |
| | | | | | | | |
| Ubuntu Launchpad[4] | Xenial/16.04 | n/a/ | no | no | yes | yes | ? |
| | Bionic/18.04 | n/a | no | no | yes | yes | ? |
| | Focal/20.04 | n/a | no | no | yes | yes | ? |
| | Impish/21.10 | n/a | no | no | yes | yes | ? |
| | Jammy/22.04 | n/a | no | no | yes | yes | ? |
| | Kinetic/22.10 | n/a | no | no | yes | yes | ? |
| | | | | | | | |
| OpenSUSE Build Service[5] | Leap15.2 | n/a | yes | yes | yes | yes | ? |
| | Leap15.3 | n/a | yes | yes | yes | yes | ? |
| | Leap15.4 | n/a | yes | yes | yes | yes | ? |
| | SLES12SP5 | n/a | yes | yes | yes | yes | ? |
| | SLES15SP2 | n/a | yes | yes | yes | yes | ? |
| | SLES15SP3 | n/a | yes | yes | yes | yes | ? |
| | SLES15SP4 | n/a | yes | yes | yes | yes | ? |
| | Tumbleweed | n/a | yes | yes | yes | yes | ? |
[1] <https://www.gluster.org/release-schedule/>
[2] <https://wiki.centos.org/SpecialInterestGroup/Storage>
[3] <https://download.gluster.org/pub/gluster/glusterfs>
[4] <https://launchpad.net/~gluster>
[5] <http://download.opensuse.org/repositories/home:/glusterfs:/>
[5] <http://download.opensuse.org/repositories/home:/glusterfs:/>
¹ Fedora Updates, UpdatesTesting, or Rawhide repository. Use dnf to install.
¹ Fedora Updates, UpdatesTesting, or Rawhide repository. Use dnf to install.

46
docs/Install-Guide/Configure.md
View File

@@ -4,7 +4,7 @@ For the Gluster to communicate within a cluster either the firewalls
have to be turned off or enable communication for each server.
```console
# iptables -I INPUT -p all -s `<ip-address>` -j ACCEPT
iptables -I INPUT -p all -s `<ip-address>` -j ACCEPT
```
### Configure the trusted pool
@@ -21,7 +21,7 @@ or IP address if you don’t have DNS or `/etc/hosts` entries.
Let say we want to connect to `node02`:
```console
# gluster peer probe node02
gluster peer probe node02
```
Notice that running `gluster peer status` from the second node shows
@@ -29,10 +29,10 @@ that the first node has already been added.
### Partition the disk
Assuming you have an empty disk at `/dev/sdb`: *(You can check the partitions on your system using* `fdisk -l`*)*
Assuming you have an empty disk at `/dev/sdb`: _(You can check the partitions on your system using_ `fdisk -l`_)_
```console
# fdisk /dev/sdb
fdisk /dev/sdb
```
And then create a single XFS partition using fdisk
@@ -40,19 +40,19 @@ And then create a single XFS partition using fdisk
### Format the partition
```console
# mkfs.xfs -i size=512 /dev/sdb1
mkfs.xfs -i size=512 /dev/sdb1
```
### Add an entry to /etc/fstab
```console
# echo "/dev/sdb1 /export/sdb1 xfs defaults 0 0" >> /etc/fstab
echo "/dev/sdb1 /export/sdb1 xfs defaults 0 0" >> /etc/fstab
```
### Mount the partition as a Gluster "brick"
```console
# mkdir -p /export/sdb1 && mount -a && mkdir -p /export/sdb1/brick
mkdir -p /export/sdb1 && mount -a && mkdir -p /export/sdb1/brick
```
#### Set up a Gluster volume
@@ -70,22 +70,22 @@ something goes wrong.
To set up a replicated volume:
```console
# gluster volume create gv0 replica 3 node01.mydomain.net:/export/sdb1/brick \
node02.mydomain.net:/export/sdb1/brick \
node03.mydomain.net:/export/sdb1/brick
gluster volume create gv0 replica 3 node01.mydomain.net:/export/sdb1/brick \
node02.mydomain.net:/export/sdb1/brick \
node03.mydomain.net:/export/sdb1/brick
```
Breaking this down into pieces:
- the first part says to create a gluster volume named gv0
(the name is arbitrary, `gv0` was chosen simply because
it’s less typing than `gluster_volume_0`).
(the name is arbitrary, `gv0` was chosen simply because
it’s less typing than `gluster_volume_0`).
- make the volume a replica volume
- keep a copy of the data on at least 3 bricks at any given time.
Since we only have three bricks total, this
means each server will house a copy of the data.
Since we only have three bricks total, this
means each server will house a copy of the data.
- we specify which nodes to use, and which bricks on those nodes. The order here is
important when you have more bricks.
important when you have more bricks.
It is possible (as of the most current release as of this writing, Gluster 3.3)
to specify the bricks in such a way that you would make both copies of the data reside on a
@@ -96,12 +96,12 @@ cluster comes to a grinding halt when a single point of failure occurs.
Now, we can check to make sure things are working as expected:
```console
# gluster volume info
gluster volume info
```
And you should see results similar to the following:
```console
```{ .console .no-copy }
Volume Name: gv0
Type: Replicate
Volume ID: 8bc3e96b-a1b6-457d-8f7a-a91d1d4dc019
@@ -115,14 +115,12 @@ Brick3: node03.yourdomain.net:/export/sdb1/brick
```
This shows us essentially what we just specified during the volume
creation. The one this to mention is the `Status`. A status of `Created`
means that the volume has been created, but hasn’t yet been started,
which would cause any attempt to mount the volume fail.
creation. The one key output worth noticing is `Status`.
A status of `Created` means that the volume has been created,
but hasn’t yet been started, which would cause any attempt to mount the volume fail.
Now, we should start the volume.
Now, we should start the volume before we try to mount it.
```
# gluster volume start gv0
gluster volume start gv0
```
Find all documentation [here](../index.md)

4
docs/Install-Guide/Install.md
View File

@@ -65,8 +65,8 @@ Finally, install the packages:
apt install glusterfs-server
```
*Note: Packages exist for Ubuntu 16.04 LTS, 18.04
LTS, 20.04 LTS, 20.10, 21.04*
_Note: Packages exist for Ubuntu 16.04 LTS, 18.04
LTS, 20.04 LTS, 20.10, 21.04_
###### For Red Hat/CentOS

69
docs/Install-Guide/Overview.md
View File

@@ -1,4 +1,5 @@
# Overview
### Purpose
The Install Guide (IG) is aimed at providing the sequence of steps needed for
@@ -30,40 +31,40 @@ this is accomplished without a centralized metadata server.
#### What is Gluster without making me learn an extra glossary of terminology?
- Gluster is an easy way to provision your own storage backend NAS
using almost any hardware you choose.
- You can add as much as you want to start with, and if you need more
later, adding more takes just a few steps.
- You can configure failover automatically, so that if a server goes
down, you don’t lose access to the data. No manual steps are
required for failover. When you fix the server that failed and bring
it back online, you don’t have to do anything to get the data back
except wait. In the meantime, the most current copy of your data
keeps getting served from the node that was still running.
- You can build a clustered filesystem in a matter of minutes… it is
trivially easy for basic setups
- It takes advantage of what we refer to as “commodity hardware”,
which means, we run on just about any hardware you can think of,
from that stack of decomm’s and gigabit switches in the corner no
one can figure out what to do with (how many license servers do you
really need, after all?), to that dream array you were speccing out
online. Don’t worry, I won’t tell your boss.
- It takes advantage of commodity software too. No need to mess with
kernels or fine tune the OS to a tee. We run on top of most unix
filesystems, with XFS and ext4 being the most popular choices. We do
have some recommendations for more heavily utilized arrays, but
these are simple to implement and you probably have some of these
configured already anyway.
- Gluster data can be accessed from just about anywhere – You can use
traditional NFS, SMB/CIFS for Windows clients, or our own native
GlusterFS (a few additional packages are needed on the client
machines for this, but as you will see, they are quite small).
- There are even more advanced features than this, but for now we will
focus on the basics.
- It’s not just a toy. Gluster is enterprise-ready, and commercial
support is available if you need it. It is used in some of the most
taxing environments like media serving, natural resource
exploration, medical imaging, and even as a filesystem for Big Data.
- Gluster is an easy way to provision your own storage backend NAS
using almost any hardware you choose.
- You can add as much as you want to start with, and if you need more
later, adding more takes just a few steps.
- You can configure failover automatically, so that if a server goes
down, you don’t lose access to the data. No manual steps are
required for failover. When you fix the server that failed and bring
it back online, you don’t have to do anything to get the data back
except wait. In the meantime, the most current copy of your data
keeps getting served from the node that was still running.
- You can build a clustered filesystem in a matter of minutes… it is
trivially easy for basic setups
- It takes advantage of what we refer to as “commodity hardware”,
which means, we run on just about any hardware you can think of,
from that stack of decomm’s and gigabit switches in the corner no
one can figure out what to do with (how many license servers do you
really need, after all?), to that dream array you were speccing out
online. Don’t worry, I won’t tell your boss.
- It takes advantage of commodity software too. No need to mess with
kernels or fine tune the OS to a tee. We run on top of most unix
filesystems, with XFS and ext4 being the most popular choices. We do
have some recommendations for more heavily utilized arrays, but
these are simple to implement and you probably have some of these
configured already anyway.
- Gluster data can be accessed from just about anywhere – You can use
traditional NFS, SMB/CIFS for Windows clients, or our own native
GlusterFS (a few additional packages are needed on the client
machines for this, but as you will see, they are quite small).
- There are even more advanced features than this, but for now we will
focus on the basics.
- It’s not just a toy. Gluster is enterprise-ready, and commercial
support is available if you need it. It is used in some of the most
taxing environments like media serving, natural resource
exploration, medical imaging, and even as a filesystem for Big Data.
#### Is Gluster going to work for me and what I need it to do?

50
docs/Install-Guide/Setup-Bare-metal.md
View File

@@ -1,5 +1,7 @@
# Setup Bare Metal
*Note: You only need one of the three setup methods!*
_Note: You only need one of the three setup methods!_
### Setup, Method 2 – Setting up on physical servers
To set up Gluster on physical servers, we recommend two servers of very
@@ -14,16 +16,16 @@ would to a production environment (in case it becomes one, as mentioned
above). That being said, here is a reminder of some of the best
practices we mentioned before:
- Make sure DNS and NTP are setup, correct, and working
- If you have access to a backend storage network, use it! 10GBE or
InfiniBand are great if you have access to them, but even a 1GBE
backbone can help you get the most out of your deployment. Make sure
that the interfaces you are going to use are also in DNS since we
will be using the hostnames when we deploy Gluster
- When it comes to disks, the more the merrier. Although you could
technically fake things out with a single disk, there would be
performance issues as soon as you tried to do any real work on the
servers
- Make sure DNS and NTP are setup, correct, and working
- If you have access to a backend storage network, use it! 10GBE or
InfiniBand are great if you have access to them, but even a 1GBE
backbone can help you get the most out of your deployment. Make sure
that the interfaces you are going to use are also in DNS since we
will be using the hostnames when we deploy Gluster
- When it comes to disks, the more the merrier. Although you could
technically fake things out with a single disk, there would be
performance issues as soon as you tried to do any real work on the
servers
With the explosion of commodity hardware, you don’t need to be a
hardware expert these days to deploy a server. Although this is
@@ -31,19 +33,19 @@ generally a good thing, it also means that paying attention to some
important, performance-impacting BIOS settings is commonly ignored. Several
points that might cause issues when if you're unaware of them:
- Most manufacturers enable power saving mode by default. This is a
great idea for servers that do not have high-performance
requirements. For the average storage server, the performance-impact
of the power savings is not a reasonable tradeoff
- Newer motherboards and processors have lots of nifty features!
Enhancements in virtualization, newer ways of doing predictive
algorithms and NUMA are just a few to mention. To be safe, many
manufactures ship hardware with settings meant to work with as
massive a variety of workloads and configurations as they have
customers. One issue you could face is when you set up that blazing-fast
10GBE card you were so thrilled about installing? In many
cases, it would end up being crippled by a default 1x speed put in
place on the PCI-E bus by the motherboard.
- Most manufacturers enable power saving mode by default. This is a
great idea for servers that do not have high-performance
requirements. For the average storage server, the performance-impact
of the power savings is not a reasonable tradeoff
- Newer motherboards and processors have lots of nifty features!
Enhancements in virtualization, newer ways of doing predictive
algorithms and NUMA are just a few to mention. To be safe, many
manufactures ship hardware with settings meant to work with as
massive a variety of workloads and configurations as they have
customers. One issue you could face is when you set up that blazing-fast
10GBE card you were so thrilled about installing? In many
cases, it would end up being crippled by a default 1x speed put in
place on the PCI-E bus by the motherboard.
Thankfully, most manufacturers show all the BIOS settings, including the
defaults, right in the manual. It only takes a few minutes to download,

94
docs/Install-Guide/Setup-aws.md
View File

@@ -1,5 +1,6 @@
# Setup AWS
*Note: You only need one of the three setup methods!*
_Note: You only need one of the three setup methods!_
### Setup, Method 3 – Deploying in AWS
@@ -7,54 +8,53 @@ Deploying in Amazon can be one of the fastest ways to get up and running
with Gluster. Of course, most of what we cover here will work with other
cloud platforms.
- Deploy at least two instances. For testing, you can use micro
instances (I even go as far as using spot instances in most cases).
Debates rage on what size instance to use in production, and there
is really no correct answer. As with most things, the real answer is
“whatever works for you”, where the trade-offs between cost and
performance are balanced in a continual dance of trying to make your
project successful while making sure there is enough money left over
in the budget for you to get that sweet new ping pong table in the
break room.
- For cloud platforms, your data is wide open right from the start. As
such, you shouldn’t allow open access to all ports in your security
groups if you plan to put a single piece of even the least valuable
information on the test instances. By least valuable, I mean “Cash
value of this coupon is 1/100th of 1 cent” kind of least valuable.
Don’t be the next one to end up as a breaking news flash on the
latest inconsiderate company to allow their data to fall into the
hands of the baddies. See Step 2 for the minimum ports you will need
open to use Gluster
- You can use the free “ephemeral” storage for the Gluster bricks
during testing, but make sure to use some form of protection against
data loss when you move to production. Typically this means EBS
backed volumes or using S3 to periodically back up your data bricks.
- Deploy at least two instances. For testing, you can use micro
instances (I even go as far as using spot instances in most cases).
Debates rage on what size instance to use in production, and there
is really no correct answer. As with most things, the real answer is
“whatever works for you”, where the trade-offs between cost and
performance are balanced in a continual dance of trying to make your
project successful while making sure there is enough money left over
in the budget for you to get that sweet new ping pong table in the
break room.
- For cloud platforms, your data is wide open right from the start. As
such, you shouldn’t allow open access to all ports in your security
groups if you plan to put a single piece of even the least valuable
information on the test instances. By least valuable, I mean “Cash
value of this coupon is 1/100th of 1 cent” kind of least valuable.
Don’t be the next one to end up as a breaking news flash on the
latest inconsiderate company to allow their data to fall into the
hands of the baddies. See Step 2 for the minimum ports you will need
open to use Gluster
- You can use the free “ephemeral” storage for the Gluster bricks
during testing, but make sure to use some form of protection against
data loss when you move to production. Typically this means EBS
backed volumes or using S3 to periodically back up your data bricks.
Other notes:
- In production, it is recommended to replicate your VM’s across
multiple zones. For purpose of this tutorial, it is overkill, but if
anyone is interested in this please let us know since we are always
looking to write articles on the most requested features and
questions.
- Using EBS volumes and Elastic IPs are also recommended in
production. For testing, you can safely ignore these as long as you
are aware that the data could be lost at any moment, so make sure
your test deployment is just that, testing only.
- Performance can fluctuate wildly in a cloud environment. If
performance issues are seen, there are several possible strategies,
but keep in mind that this is the perfect place to take advantage of
the scale-out capability of Gluster. While it is not true in all
cases that deploying more instances will necessarily result in a
“faster” cluster, in general, you will see that adding more nodes
means more performance for the cluster overall.
- If a node reboots, you will typically need to do some extra work to
get Gluster running again using the default EC2 configuration. If a
node is shut down, it can mean absolute loss of the node (depending
on how you set things up). This is well beyond the scope of this
document but is discussed in any number of AWS-related forums and
posts. Since I found out the hard way myself (oh, so you read the
manual every time?!), I thought it worth at least mentioning.
- In production, it is recommended to replicate your VM’s across
multiple zones. For purpose of this tutorial, it is overkill, but if
anyone is interested in this please let us know since we are always
looking to write articles on the most requested features and
questions.
- Using EBS volumes and Elastic IPs are also recommended in
production. For testing, you can safely ignore these as long as you
are aware that the data could be lost at any moment, so make sure
your test deployment is just that, testing only.
- Performance can fluctuate wildly in a cloud environment. If
performance issues are seen, there are several possible strategies,
but keep in mind that this is the perfect place to take advantage of
the scale-out capability of Gluster. While it is not true in all
cases that deploying more instances will necessarily result in a
“faster” cluster, in general, you will see that adding more nodes
means more performance for the cluster overall.
- If a node reboots, you will typically need to do some extra work to
get Gluster running again using the default EC2 configuration. If a
node is shut down, it can mean absolute loss of the node (depending
on how you set things up). This is well beyond the scope of this
document but is discussed in any number of AWS-related forums and
posts. Since I found out the hard way myself (oh, so you read the
manual every time?!), I thought it worth at least mentioning.
Once you have both instances up, you can proceed to the [install](./Install.md) page.

21
docs/Install-Guide/Setup-virt.md
View File

@@ -1,5 +1,6 @@
# Setup on Virtual Machine
*Note: You only need one of the three setup methods!*
_Note: You only need one of the three setup methods!_
### Setup, Method 1 – Setting up in virtual machines
@@ -16,18 +17,18 @@ distribution already.
Create or clone two VM’s, with the following setup on each:
- 2 disks using the VirtIO driver, one for the base OS and one that we
will use as a Gluster “brick”. You can add more later to try testing
some more advanced configurations, but for now let’s keep it simple.
- 2 disks using the VirtIO driver, one for the base OS and one that we
will use as a Gluster “brick”. You can add more later to try testing
some more advanced configurations, but for now let’s keep it simple.
*Note: If you have ample space available, consider allocating all the
disk space at once.*
_Note: If you have ample space available, consider allocating all the
disk space at once._
- 2 NIC’s using VirtIO driver. The second NIC is not strictly
required, but can be used to demonstrate setting up a separate
network for storage and management traffic.
- 2 NIC’s using VirtIO driver. The second NIC is not strictly
required, but can be used to demonstrate setting up a separate
network for storage and management traffic.
*Note: Attach each NIC to a separate network.*
_Note: Attach each NIC to a separate network._
Other notes: Make sure that if you clone the VM, that Gluster has not
already been installed. Gluster generates a UUID to “fingerprint” each

2
mkdocs.yml
View File

@@ -40,8 +40,8 @@ nav:
- Setting up on physical servers: Install-Guide/Setup-Bare-metal.md
- Deploying in AWS: Install-Guide/Setup-aws.md
- Install: Install-Guide/Install.md
- Community Packages: Install-Guide/Community-Packages.md
- Configure: Install-Guide/Configure.md
- Community Packages: Install-Guide/Community-Packages.md
- Administration Guide:
- Overview: Administrator-Guide/overview.md
- Index: Administrator-Guide/index.md