Skip to main content
BeeGFS on NetApp with E-Series Storage

Define the BeeGFS management service

Contributors iamjoemccormick

BeeGFS services are configured using group variables (group_vars).


This section walks through defining the BeeGFS management service. Only one service of this type should exist in the HA cluster(s) for a particular file system. Configuring this service includes defining:

  • The service type (management).

  • Defining any configuration that should only apply to this BeeGFS service.

  • Configuring one or more floating IPs (logical interfaces) where this service can be reached.

  • Specifying where/how a volume should be to store data for this service (the BeeGFS management target).


Create a new file group_vars/mgmt.yml and referencing the Plan the File System section populate it as follows:

  1. Indicate this file represents the configuration for a BeeGFS management service:

    beegfs_service: management
  2. Define any configuration that should apply only to this BeeGFS service. This is not typically required for the management service unless you need to enable quotas, however any supported configuration parameter from beegfs-mgmtd.conf can be included. Note the following parameters are configured automatically/elsewhere and should not be specified here: storeMgmtdDirectory, connAuthFile, connDisableAuthentication, connInterfacesFile, and connNetFilterFile.

  3. Configure one or more floating IPs that other services and clients will use to connect to this service (this will automatically set the BeeGFS connInterfacesFile option):

      - <INTERFACE>:<IP/SUBNET> # Primary interface. Ex. i1b:
      - <INTERFACE>:<IP/SUBNET> # Secondary interface(s) as needed.
  4. Optionally, specify one or more allowed IP subnets which may be used for outgoing communication (this will automatically set the BeeGFS connNetFilterFile option):

      - <SUBNET>/<MASK> # Ex.
  5. Specify the BeeGFS management target where this service will store data according to the following guidelines:

    1. The same storage pool or volume group name can be used for multiple BeeGFS services/targets, simply ensure to use the same name, raid_level, criteria_*, and common_* configuration for each (the volumes listed for each service should be different).

    2. Volume sizes should be specified as a percentage of the storage pool/volume group and the total should not exceed 100 across all services/volumes using a particular storage pool/volume group. Note when using SSDs it is recommended to leave some free space in the volume group to maximize SSD performance and wear life (click here for more details).

    3. Click here for a full list of configuration options available for the eseries_storage_pool_configuration. Note some options such as state, host, host_type, workload_name, and workload_metadata and volume names are generated automatically and should not be specified here.

  <BLOCK_NODE>: # The name of the block node as found in the Ansible inventory. Ex: ictad22a01
      - name: <NAME> # Ex: beegfs_m1_m2_m5_m6
        raid_level: <LEVEL> # One of: raid1, raid5, raid6, raidDiskPool
        criteria_drive_count: <DRIVE COUNT> # Ex. 4
          segment_size_kb: <SEGMENT SIZE> # Ex. 128
          - size: <PERCENT> # Percent of the pool or volume group to allocate to this volume. Ex. 1
            owning_controller: <CONTROLLER> # One of: A, B

Click here for an example of a complete inventory file representing a BeeGFS management service.