From de7d64d9f57977eb92ebad6cb2e0f48eaf8afafe Mon Sep 17 00:00:00 2001 From: "black.dragon74" Date: Thu, 19 May 2022 13:20:48 +0530 Subject: [PATCH] [Install-Guide] Fixes and improvements Also, cleaned up the syntax. Signed-off-by: black.dragon74 --- docs/Install-Guide/Common-criteria.md | 82 +++++++------- docs/Install-Guide/Community-Packages.md | 131 +++++++++++------------ docs/Install-Guide/Configure.md | 46 ++++---- docs/Install-Guide/Install.md | 4 +- docs/Install-Guide/Overview.md | 69 ++++++------ docs/Install-Guide/Setup-Bare-metal.md | 50 ++++----- docs/Install-Guide/Setup-aws.md | 94 ++++++++-------- docs/Install-Guide/Setup-virt.md | 21 ++-- mkdocs.yml | 2 +- 9 files changed, 249 insertions(+), 250 deletions(-) diff --git a/docs/Install-Guide/Common-criteria.md b/docs/Install-Guide/Common-criteria.md index 5c6aa4fc..d43edbed 100644 --- a/docs/Install-Guide/Common-criteria.md +++ b/docs/Install-Guide/Common-criteria.md @@ -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) diff --git a/docs/Install-Guide/Community-Packages.md b/docs/Install-Guide/Community-Packages.md index cb688009..0611f038 100644 --- a/docs/Install-Guide/Community-Packages.md +++ b/docs/Install-Guide/Community-Packages.md @@ -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] [2] [3] [4] -[5] +[5] -¹ Fedora Updates, UpdatesTesting, or Rawhide repository. Use dnf to install. +¹ Fedora Updates, UpdatesTesting, or Rawhide repository. Use dnf to install. diff --git a/docs/Install-Guide/Configure.md b/docs/Install-Guide/Configure.md index 6f624a0c..21051c6f 100644 --- a/docs/Install-Guide/Configure.md +++ b/docs/Install-Guide/Configure.md @@ -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 `` -j ACCEPT +iptables -I INPUT -p all -s `` -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) diff --git a/docs/Install-Guide/Install.md b/docs/Install-Guide/Install.md index 09f16b80..9feb09f3 100644 --- a/docs/Install-Guide/Install.md +++ b/docs/Install-Guide/Install.md @@ -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 diff --git a/docs/Install-Guide/Overview.md b/docs/Install-Guide/Overview.md index 5f0e42cd..adda33e4 100644 --- a/docs/Install-Guide/Overview.md +++ b/docs/Install-Guide/Overview.md @@ -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? diff --git a/docs/Install-Guide/Setup-Bare-metal.md b/docs/Install-Guide/Setup-Bare-metal.md index 682123d7..97e0cede 100644 --- a/docs/Install-Guide/Setup-Bare-metal.md +++ b/docs/Install-Guide/Setup-Bare-metal.md @@ -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, diff --git a/docs/Install-Guide/Setup-aws.md b/docs/Install-Guide/Setup-aws.md index d71d1243..342f85b7 100644 --- a/docs/Install-Guide/Setup-aws.md +++ b/docs/Install-Guide/Setup-aws.md @@ -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. diff --git a/docs/Install-Guide/Setup-virt.md b/docs/Install-Guide/Setup-virt.md index 950182cc..c6b51c78 100644 --- a/docs/Install-Guide/Setup-virt.md +++ b/docs/Install-Guide/Setup-virt.md @@ -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 diff --git a/mkdocs.yml b/mkdocs.yml index 4ea5df77..74b72daa 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -33,8 +33,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