SUSE Linux Enterprise High Availability Extension Documentation › Administration Guide › Storage and Data Replication › GFS2
ContentsContents
Administration Guide
  1. About This Guide
  2. I Installation and Setup
    1. 1 Product Overview
    2. 2 System Requirements and Recommendations
    3. 3 Installation and Basic Setup
  3. II Configuration and Administration
    1. 4 Configuration and Administration Basics
    2. 5 Configuring and Managing Cluster Resources (Web Interface)
    3. 6 Configuring and Managing Cluster Resources (Command Line)
    4. 7 Adding or Modifying Resource Agents
    5. 8 Fencing and STONITH
    6. 9 Access Control Lists
    7. 10 Network Device Bonding
    8. 11 Load Balancing
    9. 12 GEO Clusters (Multi-Site Clusters)
  4. III Storage and Data Replication
    1. 13 OCFS2
    2. 14 GFS2
    3. 15 DRBD
    4. 16 Cluster Logical Volume Manager (cLVM)
    5. 17 Storage Protection
    6. 18 Samba Clustering
    7. 19 Disaster Recovery with Rear (Relax-and-Recover)
  5. IV Appendix
    1. A Troubleshooting
    2. B Naming Conventions
    3. C Cluster Management Tools
    4. D Upgrading Your Cluster and Updating Software Packages
    5. E Documentation Updates
  6. Terminology
  7. F GNU Licenses
Navigation←→
SUSE Linux Enterprise High Availability Extension Documentation › Administration Guide › Storage and Data Replication › GFS2
Top
←→
Applies to SUSE Linux Enterprise High Availability Extension 12

14 GFS2

14.1 GFS2 Packages and Management Utilities
14.2 Configuring GFS2 Services and a STONITH Resource
14.3 Creating GFS2 Volumes
14.4 Mounting GFS2 Volumes

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 GFS2in 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.

14.1 GFS2 Packages and Management Utilities

To use GFS2, make sure gfs2-utils and 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 14.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.

14.2 Configuring GFS2 Services and a STONITH Resource

Before you can create GFS2 volumes, you must configure DLM and a STONITH resource. GFS2 uses the cluster membership services from Corosync which run in user space. Therefore, DLM needs to be configured as clone resources that are present on each node in the cluster.

Procedure 14.1: Configuring a STONITH Resource
Note
Note: STONITH Device Needed

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

  1. Start a shell and log in as root or equivalent.

  2. Create an SBD partition as described in Section 17.1.3.1, “Creating the SBD Partition”.

  3. Run crm configure.

  4. 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 \
     meta target-role="Started"

  5. Review your changes with show.

  6. If everything is correct, submit your changes with commit and leave the crm live configuration with exit.

Procedure 14.2: Configuring DLM Resources

The configuration consists of a base group that includes several primitives and a base clone. Both base group and base clone can be used in various scenarios afterwards (for both GFS2 and cLVM, for example). You only need to extend the base group with the respective primitives as needed. As the base group has internal colocation and ordering, this facilitates the overall setup as you do not have to specify several individual groups, clones and their dependencies.

Follow the steps below for one node in the cluster:

  1. Start a shell and log in as root or equivalent.

  2. Enter the following command to create the primitive resources for DLM: 

    root # crm configure primitive dlm ocf:pacemaker:controld \
     op monitor interval="60" timeout="60"

    The dlm clone resource controls the distributed lock manager service and makes sure this service is started on all nodes in the cluster. If everything is correct, answer y to submit your changes.

  3. Review your changes with show: 

    root # crm show

14.3 Creating GFS2 Volumes

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

Note
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 14.3, “Creating and Formatting an GFS2 Volume”. The most important parameters for the command are listed in Table 14.2, “Important GFS2 Parameters”. For more information and the command syntax, refer to the mkfs.gfs2 man page.

Table 14.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 14.3: Creating and Formatting an GFS2 Volume

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

  1. Open a terminal window and log in as root.

  2. Check if the cluster is online with the command crm status.

  3. 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).

14.4 Mounting GFS2 Volumes

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

Procedure 14.4: Manually Mounting an GFS2 Volume

  1. Open a terminal window and log in as root.

  2. Check if the cluster is online with the command crm status.

  3. Mount the volume from the command line, using the mount command.

Warning
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 14.5: Mounting an GFS2 Volume with the Cluster Manager

To mount an 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 Hawk to configure the resources.

  1. Start a shell and log in as root or equivalent.

  2. Run crm configure.

  3. 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"

  4. Create a base group that consists of the dlm primitive you created in Procedure 14.2, “Configuring DLM Resources” and the gfs2-1 primitive. Clone the group: 

    crm(live)configure# group base-group dlm  gfs2-1
     clone base-clone base-group \
     meta interleave="true"

    Due to the base group's internal colocation and ordering, Pacemaker will only start the gfs2-1 resource on nodes that also have an dlm resource already running.

  5. Review your changes with show.

  6. If everything is correct, submit your changes with commit and leave the crm live configuration with exit.

→Chapter 15 DRBD←Chapter 13 OCFS2
Print this page

© 2017 SUSE