LVM

gdeploy allows to setup backend for GlusterFS in two ways.

  1. Using the modules: pv, vg, and lv
  2. Using the backend-setup module.

The backend-setup module sets up a thin-pool by default and applies default performance recommendations. However, if the user has a different use case which demands more than one LV, and a combination of thin and thick pools then backend-setup is of no help. The user can use PV, VG, and LV modules to achieve this.

Both the methods are explained below:

  1. [backend-setup]
  2. PV
  3. VG
  4. LV

[backend-setup]

backend-setup module allows the user to create bricks for GlusterFS nodes. If the user needs more control on creating PV, VG, and LV refer the documentation on respective sections.

In the below example, the module creates a thinpool LV using devices sdb, sdc on all the nodes listed in the hosts section. Refer example 2x2-volume-create.conf for more complete example.:

[backend-setup]
devices=sdb,sdc
vgs=vg1,vg2
pools=pool1,pool2
lvs=lv1,lv2
mountpoints=/mnt/data1,/mnt/data2
brick_dirs=/mnt/data1/1,/mnt/data2/2

If backend-setup has to be done for particular hosts in the inventory then the section would be written like:

[backend-setup:10.0.0.100]    # Backend would be setup on just 10.0.0.100
devices=sdb,sdc
vgs=vg1,vg2
pools=pool1,pool2
lvs=lv1,lv2
mountpoints=/mnt/data1,/mnt/data2
brick_dirs=/mnt/data1/1,/mnt/data2/2

[backend-setup:10.0.0.{1..10}]    # Backend would be setup on hosts 10.0.0.1
                                    through 10.0.0.10
devices=sdb,sdc
vgs=vg1,vg2
pools=pool1,pool2
lvs=lv1,lv2
mountpoints=/mnt/data1,/mnt/data2
brick_dirs=/mnt/data1/1,/mnt/data2/2

backend-setup section supports the following variables:

  1. devices - List of comma separated devices to use.
  2. vgs - Names of the vgs. The number of vg names should match the number of devices. If name is not mentioned, default names will be generated by gdeploy.
  3. pools - Name of the thinpools. If name is not mentioned, default names will be generated by gdeploy.
  4. lvs - Logical volume names. If name is not mentioned, default names will be generated by gdeploy.
  5. size - Size of the logical volume
  6. mountpoints - Mountpoint directories. Where the logical volumes have to be mounted.
  7. brick_dirs - The brick directories to use for creating the volume.
  8. ssd - This variable is set if caching has to be added.

PV

The [pv] section allows user to create physical volumes on the given disks.

Example 1: Create a few physical volumes:

[pv]
action=create
devices=vdb,vdc,vdd

Example 2: Create a few physical volumes on a certain host:

[pv:10.0.5.2]
action=create
devices=vdb,vdc,vdd

Example 1: Wipe signature from the device and create physical volumes:

[pv]
action=create
devices=vdb,vdc,vdd
wipefs=yes

Note: By default wipefs is set to ‘no’.

Example 3: Expand an already created pv:

[pv]
action=resize
devices=vdb
expand=yes

Example 4: Shrink an already created pv:

[pv]
action=resize
devices=vdb
shrink=100G

VG

VG module currently supports two actions ‘create’ and ‘extend’.

The ‘create’ action supports four variables:

  1. pvname - The pv to be used.
  2. vgname - Name of the vg, if variable is ommitted default name GLUSTER_vg will be used.
  3. ignore_vg_errors - If set to ‘no’, gdeploy exits if an error is encountered.

Example1: Create a vg named images_vg with two PVs:

[vg]
action=create
vgname=images_vg
pvname=sdb,sdc

Example2: Create two vgs named rhgs_vg1 and rhgs_vg2 with two PVs exit gdeploy in case of any errors:

[vg]
action=create
vgname=rhgs_vg
pvname=sdb,sdc
ignore_vg_errors=no

The ‘extend’ action is used to extend volume groups. The following variables are supported if action=extend:

  1. pvname - The pv to be used, for more than one pv, comma separate them.
  2. vgname - Name of the vg, if variable is ommitted default name GLUSTER_vg will be used.
  3. ignore_vg_errors - If set to ‘no’, gdeploy exits if an error is encountered.

Example1: Extend an existing vg with the given disk:

[vg]
action=extend
vgname=rhgs_images
pvname=sdc

Example2: Extend a vg, exit gdeploy in case of errors:

[vg]
action=extend
vgname=rhgs_images
pvname=sdc
ignore_vg_errors=no

Refer hc.conf for complete example.

LV

This module is used to create, setup-cache, and convert logical volumes. The lv module supports the following variables:

  1. action - The action variable allows four values create, setup-cache, convert, and change.

If the action is create, the following options are supported:

  1. lvname - The name of the logical volume, this is an optional field. Default is GLUSTER_lv
  2. poolname - Name of the thinpool volume name, this is an optional field. Default is GLUSTER_pool
  3. lvtype - Type of the logical volume to be created, allowed values are thin and thick. This is an optional field, default is thick.
  4. size - Size of the logical volume volume. Default is to take all available space on the vg.
  5. extent - Extent size, default is 100%FREE
  6. force - Force lv create, do not ask any questions. Allowed values yes, no. This is an optional field, default is yes.
  7. vgname - Name of the volume group to use.
  8. pvname - Name of the physical volume to use.
  9. chunksize - Size of chunk for snapshot.
  10. poolmetadatasize - Sets the size of pool’s metadata logical volume.
  11. virtualsize - Creates a thinly provisioned device or a sparse device of the given size.
  12. mkfs - Creates a filesystem of the given type. Default is to use xfs.
  13. mkfs-opts - mkfs options.
  14. mount - Mount the logical volume.
  15. ignore_lv_errors - If set to no, gdeploy exits if errors are encountered.

If the action is setup-cache, the below options are supported:

  1. ssd - Name of the ssd device. For example sda/vda/ … to setup cache.
  2. vgname - Name of the volume group.
  3. poolname - Name of the pool.
  4. cache_meta_lv - Due to requirements from dm-cache (the kernel driver), LVM further splits the cache pool LV into two devices - the cache data LV and cache metadata LV. Provide the cache_meta_lv name here.
  5. cache_meta_lvsize - Size of the cache meta lv.
  6. cache_lv - Name of the cache data lv.
  7. cache_lvsize - Size of the cache data.
  8. force - Force

9. cachemode - Provides provision to setup cache while creating lv. Allowed values writeback, writethrough. Default is writethrough. 9. ignore_lv_errors - If set to no, gdeploy exits if errors are encountered.

If the action is convert, the below options are supported:

  1. lvtype - type of the lv, available options are thin and thick
  2. force - Force the lvconvert, default is yes.
  3. vgname - Name of the volume group.
  4. poolmetadata - Specifies cache or thin pool metadata logical volume.
  5. cachemode - Allowed values writeback, writethrough. Default is writethrough.
  6. cachepool - This argument is necessary when converting a logical volume to a cache LV. Name of the cachepool.
  7. lvname - Name of the logical volume.
  8. chunksize - Gives the size of chunk for snapshot, cache pool and thin pool logical volumes. Default unit is in kilobytes.
  9. poolmetadataspare - Controls creation and maintanence of pool metadata spare logical volume that will be used for automated pool recovery.
  10. thinpool - Specifies or converts logical volume into a thin pool’s data volume. Volume’s name or path has to be given.
  11. ignore_lv_errors - If set to no, gdeploy exits if errors are encountered.

If the action is change, the below options are supported:

  1. lvname - Name of the logical volume.
  2. vgname - Name of the volume group.
  3. zero - Set zeroing mode for thin pool.
  4. ignore_lv_errors - If set to no, gdeploy exits if errors are encountered.

Example 1: Create a thin LV:

[lv]
action=create
vgname=RHGS_vg1
poolname=lvthinpool
lvtype=thinpool
poolmetadatasize=10MB
chunksize=1024k
size=30GB

Example 2: Create a thick LV:

[lv]
action=create
vgname=RHGS_vg1
lvname=engine_lv
lvtype=thick
size=10GB
mount=/rhgs/brick1

If there are more than one LV, the LVs can be created by numbering the LV sections, like [lv1], [lv2] …

Refer hc.conf for complete example.