Manual Installation¶
To perform a manual installation, you have to download the BeeGFS packages and set up a few basic configuration options.
It is recommended that you start by reading the first three chapters below in order to get a basic understanding of the general installation procedure. See Quick Start Guide as a reference while performing the actual installation on your system.
Download and Installation of Packages¶
Package Repositories¶
To start an installation of BeeGFS:
Download the BeeGFS repository file for your Linux distribution from the table below to the specified directory.
Make the repository available on all nodes, either by storing it in your node boot image or by copying it to all nodes that you want to use with BeeGFS.
Install the BeeGFS services with your distribution’s package manager (e.g. “
yum install beegfs-storage
on RedHat). An overview of available packages is provided in the next section.
You can download the packages directly instead of using repositories.
Note
BeeGFS can be used in heterogeneous environments with different architectures and/or distributions.
Linux Base Distribution |
Version |
Package Manager |
Repository File (Save to…) |
---|---|---|---|
Red Hat & Rocky/Alma |
8 |
yum |
(Save to: |
SuSE Linux (and derivatives, e.g. OpenSuse, …) |
15 |
zypper |
(Save to: |
Debian GNU Linux |
10 (buster) |
apt |
(Save to: |
11 (bullseye) |
apt |
(Save to: |
|
Ubuntu |
18.04 (bionic) |
apt |
(Save to: |
20.04 (focal) |
apt |
(Save to: |
Note
When using apt
, please do not forget to run apt-get update
after adding the repository.
Repository Signature Keys¶
BeeGFS repositories and packages are digitally signed. If you would like to verify the package signatures, you can add the public BeeGFS GPG key to your package manager:
https://www.beegfs.io/release/beegfs_7.3.0/gpg/GPG-KEY-beegfs
To add the key on RedHat/SuSE, use the following command:
# rpm --import https://www.beegfs.io/release/beegfs_7.3.0/gpg/GPG-KEY-beegfs
To add the key on Debian, use the following command:
# wget -q https://www.beegfs.io/release/beegfs_7.3.0/gpg/GPG-KEY-beegfs -O- | apt-key add -
Package Descriptions¶
The following table shows the roles that need to be defined to run BeeGFS and the corresponding package for each role. BeeGFS has been designed to allow running any combination of services (e.g., metadata and storage server) on the same node. Additional information about the roles of BeeGFS nodes can be found in Architecture.
Management Server (one node)
|
beegfs-mgmtd |
Metadata Server (at least one node)
|
beegfs-meta |
Storage Server (at least one node)
|
beegfs-storage |
Client
|
beegfs-client, beegfs-helperd |
RDMA Support
|
libbeegfs-ib |
Mon - InfluxDB based Monitoring Server (optional)
|
beegfs-mon |
BeeGFS utilities for administrators
|
beegfs-utils |
BeeGFS Common
|
beegfs-common |
Note
The management server daemon, and the optional monitoring daemon has only moderate RAM and CPU requirements. As these services are not critical for file system performance, you do not need to run them on a dedicated machine. They are typically running on the cluster master node.
- Each BeeGFS service (including the client) comes with:
a config file:
/etc/beegfs/beegfs-X
systemd units
an init script:
/etc/init.d/beegfs-X
Installation does not start any of the services directly because there are a few configuration options that need to be set before the first startup. These will be described in the following sections.
Init scripts¶
Warning
Init scripts are replaced by systemd on most distributions and are only required by older operating systems installations. The only exception is the client script, which is used to trigger automatic client building and running (see below).
After installation, all services will be set to automatic startup at system boot. If you do not
want to run BeeGFS services automatically during system boot, use e.g. the chkconfig
tool to
disable automatic startup.
Another way to disable BeeGFS services startup would be to set START_SERVICENAME="NO"
in the
corresponding service configuration file (/etc/default/beegfs-X
). Note that this would have the side
effect of completely disabling init script startup of the service, not only during system boot.
Building the Client Kernel Module¶
Most parts of BeeGFS come pre-built and ready to use when you install the packages. However, the client kernel module of BeeGFS still needs to be compiled for your specific Linux kernel version.
In addition to that, it might be necessary to install the library package for RDMA support
(libbegfs-ib
), which contains the RDMA abstraction layer of BeeGFS for userspace applications
and services.
BeeGFS Client Kernel Module¶
BeeGFS client kernel modules are automatically built on startup of the beegfs-client
service
(/etc/init.d/beegfs-client
) for the currently running Linux kernel, so no manual build step is
required. The init script will also detect client package updates and kernel updates and
automatically runs a client module rebuild on next startup.
Unlike in earlier versions, RDMA support is available by default.
If you want to use a thirdparty driver though, you have to specify it in the file /etc/beegfs/beegfs-client-autobuild.conf
like this: buildArgs=-j8 OFED_INCLUDE_PATH=/usr/src/openib/include
.
To force a rebuild of the client kernel modules, you need to be root on a client node and then call:
# /etc/init.d/beegfs-client rebuild
After a successful module build, the beegfs-client needs to be restarted:
# /etc/init.d/beegfs-client restart
If the client module is unable to load, dmesg
(or /var/log/messages
) might provide
useful information.
BeeGFS RDMA Library for Server Services¶
Note
This section is only relevant if you are using InfiniBand or RoCE hardware. If not, just skip to the next section.
If you have your hardware and the correspondent drivers installed, then it is only necessary to
install the libbeegfs-ib
package to use RDMA with the server services (beegfs-meta
and
beegfs-storage
).
Basic Configuration¶
There are three configuration settings that are mandatory to be set for a specific environment. The following table shows the three settings and the configuration files, in which they will be applied:
Setting |
Configuration File (in |
---|---|
Storage Paths |
|
Management Host |
|
Client Mount Directory |
|
These are the three options that need to be set before you run the services.
Storage Paths
Set the value of the
storeMgmtDirectory
/storeMetaDirectory
/storeStorageDirectory
option to configure where BeeGFS should store its internal data. BeeGFS stores all data in a subdirectory of an existing partition that has been formatted with any of the standard local Linux file systems (typically XFS for storage servers and ext4 for metadata servers).Note that different services on the same machine cannot share the same storage directory, so different directories have to be used, e.g.
/data/beegfs-meta
for metadata servers and/data/beegfs-storage
for storage servers.Management Host
Set the value of the
sysMgmtdHost
option in the configuration files of the metadata servers, storage servers, clients, and the optional mon to the IP address or hostname of the management daemon. This will enable automatic server discovery for the clients.Client Mount Directory
The client mount file consists of two space-separated values. The first value is the directory where you want to mount the file system, and the second value is the client configuration file for this mount point. You will typically have a line like this in the
beegfs-mounts.conf
file:/mnt/beegfs /etc/beegfs/beegfs-client.conf
It is also possible to specify multiple mount/config entries in this file (one mount/config pair per line) if you need to mount different BeeGFS instances on the same client. Optionally, you can also inform mount options for each mount/config entry. In the example below, the first line mounts a writable BeeGFS FS on
/mnt/scratch
and a read-only BeeGFS FS on/mnt/software
./mnt/scratch /etc/beegfs/beegfs-client-scratch.conf beegfs rw /mnt/software /etc/beegfs/beegfs-client-software.conf beegfs ro
When you have made the changes to the configuration files, it is time to start the BeeGFS services.
Service Startup¶
The services will register themselves at the management server, so clients will automatically know about all available servers. The instructions below are for single instances. If you want to run multiple instances of one service on the same machine, please refer to Multi Mode.
Note
BeeGFS clients have a mount sanity check and cancel a mount operation if servers are
unreachable. If you want to mount even with unreachable servers, set sysMountSanityCheckMS=0
in
the file beegfs-client.conf
.
Use systemctl start beegfs-<service>
command to start the services.
Advanced Configuration and Tuning¶
Runtime configuration options can be queried and changed with the BeeGFS Control Tool (beegfs-ctl
command on the client nodes). This tool is part of the beegfs-utils package.
The beegfs-ctl
tool reads a beegfs-client.conf
file from the default location, if it exists.
While the tool can also be used without a client configuration file, it is usually much more convenient to
use when such a basic client configuration exists on the corresponding machine.
On a client with an active BeeGFS mount, several configuration options can also be queried through
procfs entries (see /proc/fs/beegfs
).
There are also several convenience helper scripts contained in the beegfs-utils package (e.g.
/usr/bin/beegfs-net
to show the currently established client connections), which either call
beegfs-ctl
internally or read output from /proc/fs/beegfs
.
Static configuration options can be set by editing the corresponding configuration files
(/etc/beegfs/beegfs-X.conf
). If you haven’t done so yet, you might want to take a look at these
files to find out which options you have in general. There is a description for each of the settings
in the corresponding configuration file.
See also
Prevent accidental registration of new nodes/targets¶
BeeGFS contains some safety options that you might want to set when your
initial file system setup is complete: storeAllowFirstRunInit=false
forbids daemon startup if the
storage directory is empty, e.g. because the corresponding RAID volume is not mounted properly.
sysAllowNewServers=false
in beegfs-mgmtd.conf
forbids registration of new servers (e.g. to make
sure a new server is not registered accidentally in a production environment).
sysMountSanityCheckMS
can be used to let the client refuse mounting the file system if not all
servers are reachable. (You will typically want to disable this option for clients that are
running together with server daemons on the same machine.)
Backups¶
We strongly recommend to setup a backup solution like rsync
, in order to
backup the management target (often /beegfs/mgmtd/
) to a safe external location. Please keep
in mind that RAID or buddy mirroring is no replacement for an external backup.
See also