GFS2 | Administration Guide | SUSE Linux Enterprise High Availability Extension 12 SP5

documentation.suse.com › Documentación de SUSE Linux Enterprise High Availability Extension › Administration Guide › Storage and Data Replication › GFS2

ContentsContents

Administration Guide

Navigation←→

Applies to SUSE Linux Enterprise High Availability Extension 12 SP5

19 GFS2 #

Abstract#

Global File System 2 or GFS2 is a shared disk file system for Linux computer clusters. GFS2 allows all nodes to have direct concurrent access to the same shared block storage. GFS2 has no disconnected operating-mode, and no client or server roles. All nodes in a GFS2 cluster function as peers. GFS2 supports up to 32 cluster nodes. Using GFS2 in a cluster requires hardware to allow access to the shared storage, and a lock manager to control access to the storage.

SUSE recommends OCFS2 over GFS2 for your cluster environments if performance is one of your major requirements. Our tests have revealed that OCFS2 performs better as compared to GFS2 in such settings.

19.1 GFS2 Packages and Management Utilities
19.2 Configuring GFS2 Services and a STONITH Resource
19.3 Creating GFS2 Volumes
19.4 Mounting GFS2 Volumes

19.1 GFS2 Packages and Management Utilities #

To use GFS2, make sure gfs2-utils and a matching gfs2-kmp-* package for your Kernel is installed on each node of the cluster.

The gfs2-utils package provides the following utilities for management of GFS2 volumes. For syntax information, see their man pages.

Table 19.1: GFS2 Utilities #

GFS2 Utility	Description
fsck.gfs2	Checks the file system for errors and optionally repairs errors.
gfs2_jadd	Adds additional journals to a GFS2 file system.
gfs2_grow	Grow a GFS2 file system.
mkfs.gfs2	Create a GFS2 file system on a device, usually a shared device or partition.
tunegfs2	Allows viewing and manipulating the GFS2 file system parameters such as `UUID`, `label`, `lockproto` and `locktable`.

19.2 Configuring GFS2 Services and a STONITH Resource #

Before you can create GFS2 volumes, you must configure DLM and a STONITH resource.

Procedure 19.1: Configuring a STONITH Resource #

Note: STONITH Device Needed

You need to configure a fencing device. Without a STONITH mechanism (like external/sbd) in place the configuration will fail.

Start a shell and log in as root or equivalent.
Create an SBD partition as described in Procedure 11.3, “Initializing the SBD Devices”.
Run crm configure.
Configure external/sbd as fencing device with /dev/sdb2 being a dedicated partition on the shared storage for heartbeating and fencing:
```
crm(live)configure# primitive sbd_stonith stonith:external/sbd \
    params pcmk_delay_max=30 meta target-role="Started"
```
Review your changes with show.
If everything is correct, submit your changes with commit and leave the crm live configuration with exit.

For details on configuring the resource group for DLM, see Procedure 17.1, “Configuring a Base Group for DLM”.

19.3 Creating GFS2 Volumes #

After you have configured DLM as cluster resources as described in Section 19.2, “Configuring GFS2 Services and a STONITH Resource”, configure your system to use GFS2 and create GFS2 volumes.

Note: GFS2 Volumes for Application and Data Files

We recommend that you generally store application files and data files on different GFS2 volumes. If your application volumes and data volumes have different requirements for mounting, it is mandatory to store them on different volumes.

Before you begin, prepare the block devices you plan to use for your GFS2 volumes. Leave the devices as free space.

Then create and format the GFS2 volume with the mkfs.gfs2 as described in Procedure 19.2, “Creating and Formatting a GFS2 Volume”. The most important parameters for the command are listed in Table 19.2, “Important GFS2 Parameters”. For more information and the command syntax, refer to the mkfs.gfs2 man page.

Table 19.2: Important GFS2 Parameters #

GFS2 Parameter	Description and Recommendation
Lock Protocol Name (`-p`)	The name of the locking protocol to use. Acceptable locking protocols are lock_dlm (for shared storage) or if you are using GFS2 as a local file system (1 node only), you can specify the lock_nolock protocol. If this option is not specified, lock_dlm protocol will be assumed.
Lock Table Name (`-t`)	The lock table field appropriate to the lock module you are using. It is clustername:fsname. clustername must match that in the cluster configuration file, `/etc/corosync/corosync.conf`. Only members of this cluster are permitted to use this file system. fsname is a unique file system name used to distinguish this GFS2 file system from others created (1 to 16 characters).
Number of Journals (`-j`)	The number of journals for gfs2_mkfs to create. You need at least one journal per machine that will mount the file system. If this option is not specified, one journal will be created.

Procedure 19.2: Creating and Formatting a GFS2 Volume #

Execute the following steps only on one of the cluster nodes.

Open a terminal window and log in as root.
Check if the cluster is online with the command crm status.
Create and format the volume using the mkfs.gfs2 utility. For information about the syntax for this command, refer to the mkfs.gfs2 man page.
For example, to create a new GFS2 file system on /dev/sdb1 that supports up to 32 cluster nodes, use the following command:
```
root # mkfs.gfs2 -t hacluster:mygfs2 -p lock_dlm -j 32 /dev/sdb1
```
The hacluster name relates to the entry cluster_name in the file /etc/corosync/corosync.conf (this is the default).

19.4 Mounting GFS2 Volumes #

You can either mount a GFS2 volume manually or with the cluster manager, as described in Procedure 19.4, “Mounting a GFS2 Volume with the Cluster Manager”.

Procedure 19.3: Manually Mounting a GFS2 Volume #

Open a terminal window and log in as root.
Check if the cluster is online with the command crm status.
Mount the volume from the command line, using the mount command.

Warning: Manually Mounted GFS2 Devices

If you mount the GFS2 file system manually for testing purposes, make sure to unmount it again before starting to use it by means of cluster resources.

Procedure 19.4: Mounting a GFS2 Volume with the Cluster Manager #

To mount a GFS2 volume with the High Availability software, configure an OCF file system resource in the cluster. The following procedure uses the crm shell to configure the cluster resources. Alternatively, you can also use Hawk2 to configure the resources.

Start a shell and log in as root or equivalent.
Run crm configure.

Configure Pacemaker to mount the GFS2 file system on every node in the cluster:

crm(live)configure# primitive gfs2-1 ocf:heartbeat:Filesystem \
  params device="/dev/sdb1" directory="/mnt/shared" fstype="gfs2" \
  op monitor interval="20" timeout="40" \
  op start timeout="60" op stop timeout="60" \
  meta target-role="Stopped"

Create a base group that consists of the dlm primitive you created in Procedure 17.1, “Configuring a Base Group for DLM” and the gfs2-1 primitive. Clone the group:
```
crm(live)configure# group g-storage dlm  gfs2-1
     clone cl-storage g-storage \
     meta interleave="true"
```
Because of the base group's internal colocation and ordering, Pacemaker will only start the gfs2-1 resource on nodes that also have a dlm resource already running.
Review your changes with show.
If everything is correct, submit your changes with commit and leave the crm live configuration with exit.

Print this page