Chapter 5. Setting Up Storage Volumes A Red Hat Gluster Storage volume is a logical collection of bricks, where each brick is an export directory on a server in the trusted storage pool. Most of the Red Hat Gluster Storage Server management operations are performed on the volume. For a detailed information about configuring Red Hat Gluster Storage for enhancing performance see, Chapter 19, Tuning for Performance Warning Red Hat does not support writing data directly into the bricks. Read and write data only through the Native Client, or through NFS or SMB mounts. Note Red Hat Gluster Storage supports IP over Infiniband (IPoIB). Install Infiniband packages on all Red Hat Gluster Storage servers and clients to support this feature. Run the yum groupinstall "Infiniband Support" to install Infiniband packages. Volume Types Distributed Distributes files across bricks in the volume. Use this volume type where scaling and redundancy requirements are not important, or provided by other hardware or software layers. See Section 5.4, "Creating Distributed Volumes" for additional information about this volume type. Replicated Replicates files across bricks in the volume. Use this volume type in environments where high-availability and high-reliability are critical. See Section 5.5, "Creating Replicated Volumes" for additional information about this volume type. Distributed Replicated Distributes files across replicated bricks in the volume. Use this volume type in environments where high-reliability and scalability are critical. This volume type offers improved read performance in most environments. See Section 5.6, "Creating Distributed Replicated Volumes" for additional information about this volume type. Arbitrated Replicated Replicates files across two bricks in a replica set, and replicates only metadata to the third brick. Use this volume type in environments where consistency is critical, but underlying storage space is at a premium. See Section 5.7, "Creating Arbitrated Replicated Volumes" for additional information about this volume type. Dispersed Disperses the file's data across the bricks in the volume. Use this volume type where you need a configurable level of reliability with a minimum space waste. See Section 5.8, "Creating Dispersed Volumes" for additional information about this volume type. Distributed Dispersed Distributes file's data across the dispersed sub-volume. Use this volume type where you need a configurable level of reliability with a minimum space waste. See Section 5.9, "Creating Distributed Dispersed Volumes" for additional information about this volume type. 5.1. Setting up Gluster Storage Volumes using gdeploy The gdeploy tool automates the process of creating, formatting, and mounting bricks. With gdeploy, the manual steps listed between Section 5.4 Formatting and Mounting Bricks and Section 5.10 Creating Distributed Dispersed Volumes are automated. When setting-up a new trusted storage pool, gdeploy could be the preferred choice of trusted storage pool set up, as manually executing numerous commands can be error prone. The advantages of using gdeploy to automate brick creation are as follows: Setting-up the backend on several machines can be done from one's laptop/desktop. This saves time and scales up well when the number of nodes in the trusted storage pool increase. Flexibility in choosing the drives to configure. (sd, vd, ...). Flexibility in naming the logical volumes (LV) and volume groups (VG). 5.1.1. Getting Started Prerequisites Generate the passphrase-less SSH keys for the nodes which are going to be part of the trusted storage pool by running the following command: Set up key-based SSH authentication access between the gdeploy controller and servers by running the following command: Note If you are using a Red Hat Gluster Storage node as the deployment node and not an external node, then the key-based SSH authentication must be set up for the Red Hat Gluster Storage node from where the installation is performed. Enable the repository required to install Ansible by running the following command: For Red Hat Enterprise Linux 8 For Red Hat Enterprise Linux 7 Install ansible by executing the following command: You must also ensure the following: Devices should be raw and unused Default system locale must be set to en_US For information on system locale, refer to the Setting the System Locale of the Red Hat Enterprise Linux 7 System Administrator's Guide . For multiple devices, use multiple volume groups, thinpool, and thinvol in the gdeploy configuration file For more information, see Installing Ansible to Support Gdeploy in Red Hat Gluster Storage 3.5 Installation Guide . gdeploy can be used to deploy Red Hat Gluster Storage in two ways: Using a node in a trusted storage pool Using a machine outside the trusted storage pool Using a node in a cluster The gdeploy package is bundled as part of the initial installation of Red Hat Gluster Storage. Using a machine outside the trusted storage pool You must ensure that the Red Hat Gluster Storage is subscribed to the required channels. For more information see, Subscribing to the Red Hat Gluster Storage Server Channels in the Red Hat Gluster Storage 3.5 Installation Guide . Execute the following command to install gdeploy: For more information on installing gdeploy see, Installing Ansible to Support Gdeploy section in the Red Hat Gluster Storage 3.5 Installation Guide . 5.1.2. Setting up a Trusted Storage Pool Creating a trusted storage pool is a tedious task and becomes more tedious as the nodes in the trusted storage pool grow. With gdeploy, just a configuration file can be used to set up a trusted storage pool. When gdeploy is installed, a sample configuration file will be created at: Note The trusted storage pool can be created either by performing each tasks, such as, setting up a backend, creating a volume, and mounting volumes independently or summed up as a single configuration. For example, for a basic trusted storage pool of a 3 x 3 replicated volume the configuration details in the configuration file will be as follows: 3x3-volume-create.conf : With this configuration a 3 x 3 replica trusted storage pool with the given IP addresses and backend device as /dev/sdb , /dev/sdc , /dev/sdd with the volume name as sample_volname will be created. For more information on possible values, see Section 5.1.7, "Configuration File" After modifying the configuration file, invoke the configuration using the command: Note You can create a new configuration file by referencing the template file available at /usr/share/doc/gdeploy/examples/gluster.conf.sample . To invoke the new configuration file, run gdeploy -c /path_to_file/config.txt command. To only setup the backend see, Section 5.1.3, "Setting up the Backend " To only create a volume see, Section 5.1.4, "Creating Volumes" To only mount clients see, Section 5.1.5, "Mounting Clients" 5.1.3. Setting up the Backend In order to setup a Gluster Storage volume, the LVM thin-p must be set up on the storage disks. If the number of machines in the trusted storage pool is huge, these tasks takes a long time, as the number of commands involved are huge and error prone if not cautious. With gdeploy, just a configuration file can be used to set up a backend. The backend is setup at the time of setting up a fresh trusted storage pool, which requires bricks to be setup before creating a volume. When gdeploy is installed, a sample configuration file will be created at: A backend can be setup in two ways: Using the [backend-setup] module Creating Physical Volume (PV), Volume Group (VG), and Logical Volume (LV) individually Note For Red Hat Enterprise Linux 6, the xfsprogs package must be installed before setting up the backend bricks using gdeploy. Important Red Hat Gluster Storage is not supported on Red Hat Enterprise Linux 6 (RHEL 6) from 3.5 Batch Update 1 onwards. See Version Details table in section Red Hat Gluster Storage Software Components and Versions of the Installation Guide 5.1.3.1. Using the [backend-setup] Module Backend setup can be done on specific machines or on all the machines. The backend-setup module internally creates PV, VG, and LV and mounts the device. Thin-p logical volumes are created as per the performance recommendations by Red Hat. The backend can be setup based on the requirement, such as: Generic Specific Generic If the disk names are uniform across the machines then backend setup can be written as below. The backend is setup for all the hosts in the `hosts' section. For more information on possible values, see Section 5.1.7, "Configuration File" Example configuration file: Backend-setup-generic.conf Specific If the disks names vary across the machines in the cluster then backend setup can be written for specific machines with specific disk names. gdeploy is quite flexible in allowing to do host specific setup in a single configuration file. For more information on possible values, see Section 5.1.7, "Configuration File" Example configuration file: backend-setup-hostwise.conf 5.1.3.2. Creating Backend by Setting up PV, VG, and LV If the user needs more control over setting up the backend, then pv, vg, and lv can be created individually. LV module provides flexibility to create more than one LV on a VG. For example, the `backend-setup' module setups 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. For more information on possible values, see Section 5.1.7, "Configuration File" The below example shows how to create four logical volumes on a single volume group. The examples shows a mix of thin and thickpool LV creation. Example to extend an existing VG: 5.1.4. Creating Volumes Setting up volume involves writing long commands by choosing the hostname/IP and brick order carefully and this could be error prone. gdeploy helps in simplifying this task. When gdeploy is installed, a sample configuration file will be created at: For example, for a basic trusted storage pool of a 4 x 3 replicate volume the configuration details in the configuration file will be as follows: For more information on possible values, see Section 5.1.7, "Configuration File" After modifying the configuration file, invoke the configuration using the command: Creating Multiple Volumes Note Support of creating multiple volumes only from gdeploy 2.0, please check your gdeploy version before trying this configuration. While creating multiple volumes in a single configuration, the [volume] modules should be numbered. For example, if there are two volumes they will be numbered [volume1], [volume2] vol-create.conf With gdeploy 2.0, a volume can be created with multiple volume options set. Number of keys should match number of values. The above configuration will create two volumes with multiple volume options set. 5.1.5. Mounting Clients When mounting clients, instead of logging into every client which has to be mounted, gdeploy can be used to mount clients remotely. When gdeploy is installed, a sample configuration file will be created at: Following is an example of the modifications to the configuration file in order to mount clients: Note If the file system type ( fstype ) is NFS, then mention it as nfs-version . The default version is 3 . For more information on possible values, see Section 5.1.7, "Configuration File" After modifying the configuration file, invoke the configuration using the command: 5.1.6. Configuring a Volume The volumes can be configured using the configuration file. The volumes can be configured remotely using the configuration file without having to log into the trusted storage pool. For more information regarding the sections and options in the configuration file, see Section 5.1.7, "Configuration File" 5.1.6.1. Adding and Removing a Brick The configuration file can be modified to add or remove a brick: Adding a Brick Modify the [volume] section in the configuration file to add a brick. For example: After modifying the configuration file, invoke the configuration using the command: Removing a Brick Modify the [volume] section in the configuration file to remove a brick. For example: Other options for state are stop, start, and force. After modifying the configuration file, invoke the configuration using the command: For more information on possible values, see Section 5.1.7, "Configuration File" 5.1.6.2. Rebalancing a Volume Modify the [volume] section in the configuration file to rebalance a volume. For example: Other options for state are stop, and fix-layout. After modifying the configuration file, invoke the configuration using the command: For more information on possible values, see Section 5.1.7, "Configuration File" 5.1.6.3. Starting, Stopping, or Deleting a Volume The configuration file can be modified to start, stop, or delete a volume: Starting a Volume Modify the [volume] section in the configuration file to start a volume. For example: After modifying the configuration file, invoke the configuration using the command: Stopping a Volume Modify the [volume] section in the configuration file to start a volume. For example: After modifying the configuration file, invoke the configuration using the command: Deleting a Volume Modify the [volume] section in the configuration file to start a volume. For example: After modifying the configuration file, invoke the configuration using the command: For more information on possible values, see Section 5.1.7, "Configuration File" 5.1.7. Configuration File The configuration file includes the various options that can be used to change the settings for gdeploy. The following options are currently supported: [hosts] [devices] [disktype] [diskcount] [stripesize] [vgs] [pools] [lvs] [mountpoints] [peer] [clients] [volume] [backend-setup] [pv] [vg] [lv] [RH-subscription] [yum] [shell] [update-file] [service] [script] [firewalld] [geo-replication] The options are briefly explained in the following list: hosts This is a mandatory section which contains the IP address or hostname of the machines in the trusted storage pool. Each hostname or IP address should be listed in a separate line. For example: devices This is a generic section and is applicable to all the hosts listed in the [hosts] section. However, if sections of hosts such as the [hostname] or [IP-address] is present, then the data in the generic sections like [devices] is ignored. Host specific data take precedence. This is an optional section. For example: Note When configuring the backend setup, the devices should be either listed in this section or in the host specific section. disktype This section specifies the disk configuration that is used while setting up the backend. gdeploy supports RAID 10, RAID 6, RAID 5, and JBOD configurations. This is an optional section and if the field is left empty, JBOD is taken as the default configuration. Valid values for this field are raid10 , raid6 , raid5 , and jbod . For example: diskcount This section specifies the number of data disks in the setup. This is a mandatory field if a RAID disk type is specified under [disktype] . If the [disktype] is JBOD the [diskcount] value is ignored. This parameter is host specific. For example: stripesize This section specifies the stripe_unit size in KB. Case 1: This field is not necessary if the [disktype] is JBOD, and any given value will be ignored. Case 2: This is a mandatory field if [disktype] is specified as RAID 5 or RAID 6. For [disktype] RAID 10, the default value is taken as 256KB. Red Hat does not recommend changing this value. If you specify any other value the following warning is displayed: Note Do not add any suffixes like K, KB, M, etc. This parameter is host specific and can be added in the hosts section. For example: vgs This section is deprecated in gdeploy 2.0. Please see [backend-setup] for more details for gdeploy 2.0. This section specifies the volume group names for the devices listed in [devices]. The number of volume groups in the [vgs] section should match the one in [devices]. If the volume group names are missing, the volume groups will be named as GLUSTER_vg{1, 2, 3, ...} as default. For example: pools This section is deprecated in gdeploy 2.0. Please see [backend-setup] for more details for gdeploy 2.0. This section specifies the pool names for the volume groups specified in the [vgs] section. The number of pools listed in the [pools] section should match the number of volume groups in the [vgs] section. If the pool names are missing, the pools will be named as GLUSTER_pool{1, 2, 3, ...}. For example: lvs This section is deprecated in gdeploy 2.0. Please see [backend-setup] for more details for gdeploy 2.0. This section provides the logical volume names for the volume groups specified in [vgs]. The number of logical volumes listed in the [lvs] section should match the number of volume groups listed in [vgs]. If the logical volume names are missing, it is named as GLUSTER_lv{1, 2, 3, ...}. For example: mountpoints This section is deprecated in gdeploy 2.0. Please see [backend-setup] for more details for gdeploy 2.0. This section specifies the brick mount points for the logical volumes. The number of mount points should match the number of logical volumes specified in [lvs] If the mount points are missing, the mount points will be names as /gluster/brick{1, 2, 3...}. For example: peer This section specifies the configurations for the Trusted Storage Pool management (TSP). This section helps in making all the hosts specified in the [hosts] section to either probe each other to create the trusted storage pool or detach all of them from the trusted storage pool. The only option in this section is the option names 'action' which can have it's values to be either probe or detach. For example: clients This section specifies the client hosts and client_mount_points to mount the gluster storage volume created. The 'action' option is to be specified for the framework to determine the action that has to be performed. The options are 'mount' and 'unmount'. The Client hosts field is mandatory. If the mount points are not specified, default will be taken as /mnt/gluster for all the hosts. The option fstype specifies how the gluster volume is to be mounted. Default is glusterfs (FUSE mount). The volume can also be mounted as NFS. Each client can have different types of volume mount, which has to be specified with a comma separated. The following fields are included: For example: volume The section specifies the configuration options for the volume. The following fields are included in this section: action This option specifies what action must be performed in the volume. The choices can be [create, delete, add-brick, remove-brick]. create : This choice is used to create a volume. delete : If the delete choice is used, all the options other than 'volname' will be ignored. add-brick or remove-brick : If the add-brick or remove-brick is chosen, extra option bricks with a comma separated list of brick names(in the format <hostname>:<brick path> should be provided. In case of remove-brick, state option should also be provided specifying the state of the volume after brick removal. volname This option specifies the volume name. Default name is glustervol Note In case of a volume operation, the 'hosts' section can be omitted, provided volname is in the format <hostname>:<volname>, where hostname is the hostname / IP of one of the nodes in the cluster Only single volume creation/deletion/configuration is supported. transport This option specifies the transport type. Default is tcp. Options are tcp or rdma (Deprecated) or tcp,rdma. replica This option will specify if the volume should be of type replica. options are yes and no. Default is no. If 'replica' is provided as yes, the 'replica_count' should be provided. disperse This option specifies if the volume should be of type disperse. Options are yes and no. Default is no. disperse_count This field is optional even if 'disperse' is yes. If not specified, the number of bricks specified in the command line is taken as the disperse_count value. redundancy_count If this value is not specified, and if 'disperse' is yes, it's default value is computed so that it generates an optimal configuration. force This is an optional field and can be used during volume creation to forcefully create the volume. For example: backend-setup Available in gdeploy 2.0. This section sets up the backend for using with GlusterFS volume. If more than one backend-setup has to be done, they can be done by numbering the section like [backend-setup1], [backend-setup2], ... backend-setup section supports the following variables: devices: This replaces the [pvs] section in gdeploy 1.x. devices variable lists the raw disks which should be used for backend setup. For example: This is a mandatory field. dalign: The Logical Volume Manager can use a portion of the physical volume for storing its metadata while the rest is used as the data portion. Align the I/O at the Logical Volume Manager (LVM) layer using the dalign option while creating the physical volume. For example: For JBOD, use an alignment value of 256K. For hardware RAID, the alignment value should be obtained by multiplying the RAID stripe unit size with the number of data disks. If 12 disks are used in a RAID 6 configuration, the number of data disks is 10; on the other hand, if 12 disks are used in a RAID 10 configuration, the number of data disks is 6. The following example is appropriate for 12 disks in a RAID 6 configuration with a stripe unit size of 128 KiB: The following example is appropriate for 12 disks in a RAID 10 configuration with a stripe unit size of 256 KiB: To view the previously configured physical volume settings for the dalign option, run the pvs -o +pe_start device command. For example: You can also set the dalign option in the PV section. vgs: This is an optional variable. This variable replaces the [vgs] section in gdeploy 1.x. vgs variable lists the names to be used while creating volume groups. The number of VG names should match the number of devices or should be left blank. gdeploy will generate names for the VGs. For example: A pattern can be provided for the vgs like custom_vg{1..3}, this will create three vgs. pools: This is an optional variable. The variable replaces the [pools] section in gdeploy 1.x. pools lists the thin pool names for the volume. Similar to vg, pattern can be provided for thin pool names. For example custom_pool{1..3} lvs: This is an optional variable. This variable replaces the [lvs] section in gdeploy 1.x. lvs lists the logical volume name for the volume. Patterns for LV can be provided similar to vg. For example custom_lv{1..3}. mountpoints: This variable deprecates the [mountpoints] section in gdeploy 1.x. Mountpoints lists the mount points where the logical volumes should be mounted. Number of mount points should be equal to the number of logical volumes. For example: ssd - This variable is set if caching has to be added. For example, the backed setup with ssd for caching should be: Note Specifying the name of the data LV is necessary while adding SSD. Make sure the datalv is created already. Otherwise ensure to create it in one of the earlier `backend-setup' sections. PV Available in gdeploy 2.0. If the user needs to have more control over setting up the backend, and does not want to use backend-setup section, then pv, vg, and lv modules are to be used. The pv module supports the following variables. action: Mandatory. Supports two values, 'create' and 'resize' Example: Creating physical volumes Example: Creating physical volumes on a specific host devices: Mandatory. The list of devices to use for pv creation. expand: Used when action=resize . Example: Expanding an already created pv shrink: Used when action=resize . Example: Shrinking an already created pv dalign: The Logical Volume Manager can use a portion of the physical volume for storing its metadata while the rest is used as the data portion. Align the I/O at the Logical Volume Manager (LVM) layer using the dalign option while creating the physical volume. For example: For JBOD, use an alignment value of 256K. For hardware RAID, the alignment value should be obtained by multiplying the RAID stripe unit size with the number of data disks. If 12 disks are used in a RAID 6 configuration, the number of data disks is 10; on the other hand, if 12 disks are used in a RAID 10 configuration, the number of data disks is 6. The following example is appropriate for 12 disks in a RAID 6 configuration with a stripe unit size of 128 KiB: The following example is appropriate for 12 disks in a RAID 10 configuration with a stripe unit size of 256 KiB: To view the previously configured physical volume settings for the dalign option, run the pvs -o +pe_start device command. For example: You can also set the dalign option in the backend-setup section. VG Available in gdeploy 2.0. This module is used to create and extend volume groups. The vg module supports the following variables. action - Action can be one of create or extend. pvname - PVs to use to create the volume. For more than one PV use comma separated values. vgname - The name of the vg. If no name is provided GLUSTER_vg will be used as default name. one-to-one - If set to yes, one-to-one mapping will be done between pv and vg. If action is set to extend, the vg will be extended to include pv provided. Example1: Create a vg named images_vg with two PVs Example2: Create two vgs named rhgs_vg1 and rhgs_vg2 with two PVs Example3: Extend an existing vg with the given disk. LV Available in gdeploy 2.0. This module is used to create, setup-cache, and convert logical volumes. The lv module supports the following variables: action - The action variable allows three values `create', `setup-cache', `convert', and `change'. If the action is 'create', the following options are supported: lvname: The name of the logical volume, this is an optional field. Default is GLUSTER_lv poolname - Name of the thinpool volume name, this is an optional field. Default is GLUSTER_pool lvtype - Type of the logical volume to be created, allowed values are `thin' and `thick'. This is an optional field, default is thick. size - Size of the logical volume volume. Default is to take all available space on the vg. extent - Extent size, default is 100%FREE force - Force lv create, do not ask any questions. Allowed values `yes', `no'. This is an optional field, default is yes. vgname - Name of the volume group to use. pvname - Name of the physical volume to use. chunksize - The size of the chunk unit used for snapshots, cache pools, and thin pools. By default this is specified in kilobytes. For RAID 5 and 6 volumes, gdeploy calculates the default chunksize by multiplying the stripe size and the disk count. For RAID 10, the default chunksize is 256 KB. See Section 19.2, "Brick Configuration" for details. Warning Red Hat recommends using at least the default chunksize. If the chunksize is too small and your volume runs out of space for metadata, the volume is unable to create data. This includes the data required to increase the size of the metadata pool or to migrate data away from a volume that has run out of metadata space. Red Hat recommends monitoring your logical volumes to ensure that they are expanded or more storage created before metadata volumes become completely full. poolmetadatasize - Sets the size of pool's metadata logical volume. Allocate the maximum chunk size (16 GiB) if possible. If you allocate less than the maximum, allocate at least 0.5% of the pool size to ensure that you do not run out of metadata space. Warning If your metadata pool runs out of space, you cannot create data. This includes the data required to increase the size of the metadata pool or to migrate data away from a volume that has run out of metadata space. Monitor your metadata pool using the lvs -o+metadata_percent command and ensure that it does not run out of space. virtualsize - Creates a thinly provisioned device or a sparse device of the given size mkfs - Creates a filesystem of the given type. Default is to use xfs. mkfs-opts - mkfs options. mount - Mount the logical volume. If the action is setup-cache, the below options are supported: ssd - Name of the ssd device. For example sda/vda/ ... to setup cache. vgname - Name of the volume group. poolname - Name of the pool. 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. cache_meta_lvsize - Size of the cache meta lv. cache_lv - Name of the cache data lv. cache_lvsize - Size of the cache data. force - Force If the action is convert, the below options are supported: lvtype - type of the lv, available options are thin and thick force - Force the lvconvert, default is yes. vgname - Name of the volume group. poolmetadata - Specifies cache or thin pool metadata logical volume. cachemode - Allowed values writeback, writethrough. Default is writethrough. cachepool - This argument is necessary when converting a logical volume to a cache LV. Name of the cachepool. lvname - Name of the logical volume. chunksize - The size of the chunk unit used for snapshots, cache pools, and thin pools. By default this is specified in kilobytes. For RAID 5 and 6 volumes, gdeploy calculates the default chunksize by multiplying the stripe size and the disk count. For RAID 10, the default chunksize is 256 KB. See Section 19.2, "Brick Configuration" for details. Warning Red Hat recommends using at least the default chunksize. If the chunksize is too small and your volume runs out of space for metadata, the volume is unable to create data. Red Hat recommends monitoring your logical volumes to ensure that they are expanded or more storage created before metadata volumes become completely full. poolmetadataspare - Controls creation and maintanence of pool metadata spare logical volume that will be used for automated pool recovery. thinpool - Specifies or converts logical volume into a thin pool's data volume. Volume's name or path has to be given. If the action is change, the below options are supported: lvname - Name of the logical volume. vgname - Name of the volume group. zero - Set zeroing mode for thin pool. Example 1: Create a thin LV Example 2: Create a thick LV If there are more than one LVs, then the LVs can be created by numbering the LV sections, like [lv1], [lv2] ... RH-subscription Available in gdeploy 2.0. This module is used to subscribe, unsubscribe, attach, enable repos etc. The RH-subscription module allows the following variables: This module is used to subscribe, unsubscribe, attach, enable repos etc. The RH-subscription module allows the following variables: If the action is register , the following options are supported: username/activationkey: Username or activationkey. password/activationkey: Password or activation key auto-attach: true/false pool: Name of the pool. repos: Repos to subscribe to. disable-repos: Repo names to disable. Leaving this option blank will disable all the repos. ignore_register_errors: If set to no, gdeploy will exit if system registration fails. If the action is attach-pool the following options are supported: pool - Pool name to be attached. ignore_attach_pool_errors - If set to no, gdeploy fails if attach-pool fails. If the action is enable-repos the following options are supported: repos - List of comma separated repos that are to be subscribed to. ignore_enable_errors - If set to no, gdeploy fails if enable-repos fail. If the action is disable-repos the following options are supported: repos - List of comma separated repos that are to be subscribed to. ignore_disable_errors - If set to no, gdeploy fails if disable-repos fail If the action is unregister the systems will be unregistered. ignore_unregister_errors - If set to no, gdeploy fails if unregistering fails. Example 1: Subscribe to Red Hat Subscription network: Example 2: Disable all the repos: Example 3: Enable a few repos yum Available in gdeploy 2.0. This module is used to install or remove rpm packages, with the yum module we can add repos as well during the install time. The action variable allows two values `install' and `remove'. If the action is install the following options are supported: packages - Comma separated list of packages that are to be installed. repos - The repositories to be added. gpgcheck - yes/no values have to be provided. update - Whether yum update has to be initiated. If the action is remove then only one option has to be provided: remove - The comma separated list of packages to be removed. For example Install a package on a particular host. shell Available in gdeploy 2.0. This module allows user to run shell commands on the remote nodes. Currently shell provides a single action variable with value execute. And a command variable with any valid shell command as value. The below command will execute vdsm-tool on all the nodes. update-file Available in gdeploy 2.0. update-file module allows users to copy a file, edit a line in a file, or add new lines to a file. action variable can be any of copy, edit, or add. When the action variable is set to copy, the following variables are supported. src - The source path of the file to be copied from. dest - The destination path on the remote machine to where the file is to be copied to. When the action variable is set to edit, the following variables are supported. dest - The destination file name which has to be edited. replace - A regular expression, which will match a line that will be replaced. line - Text that has to be replaced. When the action variable is set to add, the following variables are supported. dest - File on the remote machine to which a line has to be added. line - Line which has to be added to the file. Line will be added towards the end of the file. Example 1: Copy a file to a remote machine. Example 2: Edit a line in the remote machine, in the below example lines that have allowed_hosts will be replaced with allowed_hosts=host.redhat.com Example 3: Add a line to the end of a file For Red Hat Enterprise Linux 7: For Red Hat Enterprise Linux 8: service Available in gdeploy 2.0. The service module allows user to start, stop, restart, reload, enable, or disable a service. The action variable specifies these values. When action variable is set to any of start, stop, restart, reload, enable, disable the variable servicename specifies which service to start, stop etc. service - Name of the service to start, stop etc. For Red Hat Enterprise Linux 7: Example: enable and start ntp daemon. For Red Hat Enterprise Linux 8: Example: enable and start chrony daemon. script Available in gdeploy 2.0. script module enables user to execute a script/binary on the remote machine. action variable is set to execute. Allows user to specify two variables file and args. file - An executable on the local machine. args - Arguments to the above program. Example: Execute script disable-multipath.sh on all the remote nodes listed in `hosts' section. firewalld Available in gdeploy 2.0. firewalld module allows the user to manipulate firewall rules. action variable supports two values `add' and `delete'. Both add and delete support the following variables: ports/services - The ports or services to add to firewall. permanent - Whether to make the entry permanent. Allowed values are true/false zone - Default zone is public For example: geo-replication Available in gdeploy 2.0.2, geo-replication module allows the user to configure geo-replication, control and verify geo-replication sessions. The following are the supported variables: action - The action to be performed for the geo-replication session. create - To create a geo-replication session. start - To start a created geo-replication session. stop - To stop a started geo-replication session. pause - To pause a geo-replication session. resume - To resume a paused geo-replication session. delete - To delete a geo-replication session. georepuser - Username to be used for the action being performed Important If georepuser variable is omitted, the user is assumed to be root user. mastervol - Master volume details in the following format: slavevol - Slave volume details in the following format: slavenodes - Slave node IP addresses in the following format: Important Slave IP addresses must be comma (,) separated. force - Force the system to perform the action. Allowed values are yes or no . start - Start the action specified in the configuration file. Allowed values are yes or no . Default value is yes . For example: 5.1.8. Deploying NFS Ganesha using gdeploy gdeploy supports the deployment and configuration of NFS Ganesha on Red Hat Gluster Storage 3.5, from gdeploy version 2.0.2-35. NFS-Ganesha is a user space file server for the NFS protocol. For more information about NFS-Ganesha see https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html-single/administration_guide/#nfs_ganesha 5.1.8.1. Prerequisites Ensure that the following prerequisites are met: Subscribing to Subscription Manager You must subscribe to subscription manager and obtain the NFS Ganesha packages before continuing further. Add the following details to the configuration file to subscribe to subscription manager: Execute the following command to run the configuration file: Enabling Repos To enable the required repos, add the following details in the configuration file: Execute the following command to run the configuration file: Enabling Firewall Ports To enable the firewall ports, add the following details in the configuration file: Note To ensure NFS client UDP mount does not fail, ensure to add port 2049/udp in [firewalld] section of gdeploy. Execute the following command to run the configuration file: Installing the Required Package: To install the required package, add the following details in the configuration file Execute the following command to run the configuration file: 5.1.8.2. Supported Actions The NFS Ganesha module in gdeploy allows the user to perform the following actions: Creating a Cluster Destroying a Cluster Adding a Node Deleting a Node Exporting a Volume Unexporting a Volume Refreshing NFS Ganesha Configuration Creating a Cluster This action creates a fresh NFS-Ganesha setup on a given volume. For this action the nfs-ganesha in the configuration file section supports the following variables: ha-name : This is an optional variable. By default it is ganesha-ha-360. cluster-nodes : This is a required argument. This variable expects comma separated values of cluster node names, which is used to form the cluster. vip : This is a required argument. This variable expects comma separated list of ip addresses. These will be the virtual ip addresses. volname : This is an optional variable if the configuration contains the [volume] section For example: To create a NFS-Ganesha cluster add the following details in the configuration file: In the above example, it is assumed that the required packages are installed, a volume is created and NFS-Ganesha is enabled on it. Execute the configuration using the following command: Destroying a Cluster The action, destroy-cluster cluster disables NFS Ganesha. It allows one variable, cluster-nodes . For example: To destroy a NFS-Ganesha cluster add the following details in the configuration file: Execute the configuration using the following command: Adding a Node The add-node action allows three variables: nodes : Accepts a list of comma separated hostnames that have to be added to the cluster vip : Accepts a list of comma separated ip addresses. cluster_nodes : Accepts a list of comma separated nodes of the NFS Ganesha cluster. For example, to add a node, add the following details to the configuration file: Note With the release of 3.5 Batch Update 3, the mount point of shared storage is changed from /var/run/gluster/ to /run/gluster/ . Execute the configuration using the following command: Deleting a Node The delete-node action takes one variable, nodes , which specifies the node or nodes to delete from the NFS Ganesha cluster in a comma delimited list. For example: Exporting a Volume This action exports a volume. export-volume action supports one variable, volname . For example, to export a volume, add the following details to the configuration file: Execute the configuration using the following command: Unexporting a Volume: This action unexports a volume. unexport-volume action supports one variable, volname . For example, to unexport a volume, add the following details to the configuration file: Execute the configuration using the following command: Refreshing NFS Ganesha Configuration This action will add/delete or add a config block to the configuration file and runs refresh-config on the cluster. The action refresh-config supports the following variables: del-config-lines block-name volname ha-conf-dir update_config_lines Example 1 - To add a client block and run refresh-config add the following details to the configuration file: Note refresh-config with client block has few limitations: Works for only one client User cannot delete a line from a config block Execute the configuration using the following command: Example 2 - To delete a line and run refresh-config add the following details to the configuration file: Execute the configuration using the following command: Example 3 - To run refresh-config on a volume add the following details to the configuration file: Execute the configuration using the following command: Example 4 - To modify a line and run refresh-config add the following details to the configuration file: Execute the configuration using the following command: 5.1.9. Deploying Samba / CTDB using gdeploy The Server Message Block (SMB) protocol can be used to access Red Hat Gluster Storage volumes by exporting directories in GlusterFS volumes as SMB shares on the server. In Red Hat Gluster Storage, Samba is used to share volumes through SMB protocol. 5.1.9.1. Prerequisites Ensure that the following prerequisites are met: Subscribing to Subscription Manager You must subscribe to subscription manager and obtain the Samba packages before continuing further. Add the following details to the configuration file to subscribe to subscription manager: Execute the following command to run the configuration file: Enabling Repos To enable the required repos, add the following details in the configuration file: Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 8 Execute the following command to run the configuration file: Enabling Firewall Ports To enable the firewall ports, add the following details in the configuration file: Execute the following command to run the configuration file: Installing the Required Package: To install the required package, add the following details in the configuration file Execute the following command to run the configuration file: 5.1.9.2. Setting up Samba Samba can be enabled in two ways: Enabling Samba on an existing volume Enabling Samba while creating a volume Enabling Samba on an existing volume If a Red Hat Gluster Storage volume is already present, then the user has to mention the action as smb-setup in the volume section. It is necessary to mention all the hosts that are in the cluster, as gdeploy updates the glusterd configuration files on each of the hosts. For example, to enable Samba on an existing volume, add the following details to the configuration file: Note Ensure that the hosts are not part of the CTDB cluster. Execute the configuration using the following command: Enabling Samba while creating a Volume If Samba has be set up while creating a volume, the a variable smb has to be set to yes in the configuration file. For example, to enable Samba while creating a volume, add the following details to the configuration file: Execute the configuration using the following command: Note In both the cases of enabling Samba, smb_username and smb_mountpoint are necessary if samba has to be setup with the acls set correctly. 5.1.9.3. Setting up CTDB Using CTDB requires setting up a separate volume in order to protect the CTDB lock file. Red Hat recommends a replicated volume where the replica count is equal to the number of servers being used as Samba servers. The following configuration file sets up a CTDB volume across two hosts that are also Samba servers. You can configure the CTDB cluster to use separate IP addresses by using the ctdb_nodes parameter, as shown in the following example. Execute the configuration using the following command: 5.1.10. Enabling SSL on a Volume You can create volumes with SSL enabled, or enable SSL on an exisiting volumes using gdeploy (v2.0.1 onwards). This section explains how the configuration files should be written for gdeploy to enable SSL. 5.1.10.1. Creating a Volume and Enabling SSL To create a volume and enable SSL on it, add the following details to the configuration file: In the above example, a volume named vol1 is created and SSL is enabled on it. gdeploy creates self signed certificates. After adding the details to the configuration file, execute the following command to run the configuration file: 5.1.10.2. Enabling SSL on an Existing Volume: To enable SSL on an existing volume, add the following details to the configuration file: After adding the details to the configuration file, execute the following command to run the configuration file: 5.1.11. Gdeploy log files Because gdeploy is usually run by non-privileged users, by default, gdeploy log files are written to /home/ username /.gdeploy/logs/gdeploy.log instead of the /var/log directory. You can change the log location by setting a different location as the value of the GDEPLOY_LOGFILE environment variable. For example, to set the gdeploy log location to /var/log/gdeploy/gdeploy.log for this session, run the following command: To persistently set this as the default log location for this user, add the same command as a separate line in the /home/ username /.bash_profile file for that user.

Commands:
ssh-keygen -t rsa -N ''
ssh-copy-id -i root@ server
subscription-manager repos --enable=ansible-2-for-rhel-8-x86_64-rpms
subscription-manager repos --enable=rhel-7-server-ansible-2-rpms
yum install ansible
yum install gdeploy
/usr/share/doc/gdeploy/examples/gluster.conf.sample
# Usage: gdeploy -c 3x3-volume-create.conf # This does backend setup first and then create the volume using the setup bricks. # # [hosts] 10.70.46.13 10.70.46.17 10.70.46.21 Common backend setup for 2 of the hosts. [backend-setup] devices=sdb,sdc,sdd vgs=vg1,vg2,vg3 pools=pool1,pool2,pool3 lvs=lv1,lv2,lv3 mountpoints=/rhgs/brick1,/rhgs/brick2,/rhgs/brick3 brick_dirs=/rhgs/brick1/b1,/rhgs/brick2/b2,/rhgs/brick3/b3 If backend-setup is different for each host [backend-setup:10.70.46.13] devices=sdb brick_dirs=/rhgs/brick1 # [backend-setup:10.70.46.17] devices=sda,sdb,sdc brick_dirs=/rhgs/brick{1,2,3} # [volume] action=create volname=sample_volname replica=yes replica_count=3 force=yes [clients] action=mount volname=sample_volname hosts=10.70.46.15 fstype=glusterfs client_mount_points=/mnt/gluster
gdeploy -c txt.conf
/usr/share/doc/gdeploy/examples/gluster.conf.sample
# Usage: gdeploy -c backend-setup-generic.conf # This configuration creates backend for GlusterFS clusters # [hosts] 10.70.46.130 10.70.46.32 10.70.46.110 10.70.46.77 Backend setup for all the nodes in the `hosts' section. This will create PV, VG, and LV with gdeploy generated names. [backend-setup] devices=vdb
# Usage: gdeploy -c backend-setup-hostwise.conf # This configuration creates backend for GlusterFS clusters # [hosts] 10.70.46.130 10.70.46.32 10.70.46.110 10.70.46.77 Backend setup for 10.70.46.77 with default gdeploy generated names for Volume Groups and Logical Volumes. Volume names will be GLUSTER_vg1, GLUSTER_vg2 [backend-setup:10.70.46.77] devices=vda,vdb Backend setup for remaining 3 hosts in the `hosts' section with custom names for Volumes Groups and Logical Volumes. [backend-setup:10.70.46.{130,32,110}] devices=vdb,vdc,vdd vgs=vg1,vg2,vg3 pools=pool1,pool2,pool3 lvs=lv1,lv2,lv3 mountpoints=/rhgs/brick1,/rhgs/brick2,/rhgs/brick3 brick_dirs=/rhgs/brick1/b1,/rhgs/brick2/b2,/rhgs/brick3/b3
[hosts] 10.70.46.130 10.70.46.32 [pv] action=create devices=vdb [vg1] action=create vgname=RHS_vg1 pvname=vdb [lv1] action=create vgname=RHS_vg1 lvname=engine_lv lvtype=thick size=10GB mount=/rhgs/brick1 [lv2] action=create vgname=RHS_vg1 poolname=lvthinpool lvtype=thinpool poolmetadatasize=200MB chunksize=1024k size=30GB [lv3] action=create lvname=lv_vmaddldisks poolname=lvthinpool vgname=RHS_vg1 lvtype=thinlv mount=/rhgs/brick2 virtualsize=9GB [lv4] action=create lvname=lv_vmrootdisks poolname=lvthinpool vgname=RHS_vg1 size=19GB lvtype=thinlv mount=/rhgs/brick3 virtualsize=19GB
# Extends a given given VG. pvname and vgname is mandatory, in this example the vg `RHS_vg1' is extended by adding pv, vdd. If the pv is not alreay present, it is created by gdeploy. # [hosts] 10.70.46.130 10.70.46.32 [vg2] action=extend vgname=RHS_vg1 pvname=vdd
/usr/share/doc/gdeploy/examples/gluster.conf.sample
[hosts] 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4 [volume] action=create volname=glustervol transport=tcp,rdma replica=yes replica_count=3 brick_dirs=/glus/brick1/b1,/glus/brick1/b1,/glus/brick1/b1 force=yes
gdeploy -c txt.conf
[hosts] 10.70.46.130 10.70.46.32 10.70.46.16 [backend-setup] devices=vdb,vdc,vdd,vde mountpoints=/mnt/data{1-6} brick_dirs=/mnt/data1/1,/mnt/data2/2,/mnt/data3/3,/mnt/data4/4,/mnt/data5/5,/mnt/data6/6 [volume1] action=create volname=vol-one transport=tcp replica=yes replica_count=3 brick_dirs=/mnt/data1/1,/mnt/data2/2,/mnt/data5/5 [volume2] action=create volname=vol-two transport=tcp replica=yes replica_count=3 brick_dirs=/mnt/data3/3,/mnt/data4/4,/mnt/data6/6
[hosts] 10.70.46.130 10.70.46.32 10.70.46.16 [backend-setup] devices=vdb,vdc mountpoints=/mnt/data{1-6} [volume1] action=create volname=vol-one transport=tcp replica=yes replica_count=3 key=group,storage.owner-uid,storage.owner-gid,features.shard,features.shard-block-size,performance.low-prio-threads,cluster.data-self-heal-algorithm value=virt,36,36,on,512MB,32,full brick_dirs=/mnt/data1/1,/mnt/data3/3,/mnt/data5/5 [volume2] action=create volname=vol-two transport=tcp replica=yes key=group,storage.owner-uid,storage.owner-gid,features.shard,features.shard-block-size,performance.low-prio-threads,cluster.data-self-heal-algorithm value=virt,36,36,on,512MB,32,full replica_count=3 brick_dirs=/mnt/data2/2,/mnt/data4/4,/mnt/data6/6
/usr/share/doc/gdeploy/examples/gluster.conf.sample
[clients] action=mount hosts=10.70.46.159 fstype=glusterfs client_mount_points=/mnt/gluster volname=10.0.0.1:glustervol
gdeploy -c txt.conf
[volume] action=add-brick volname=10.0.0.1:glustervol bricks=10.0.0.1:/rhgs/new_brick
gdeploy -c txt.conf
[volume] action=remove-brick volname=10.0.0.1:glustervol bricks=10.0.0.2:/rhgs/brick state=commit
gdeploy -c txt.conf
[volume] action=rebalance volname=10.70.46.13:glustervol state=start
gdeploy -c txt.conf
[volume] action=start volname=10.0.0.1:glustervol
gdeploy -c txt.conf
[volume] action=stop volname=10.0.0.1:glustervol
gdeploy -c txt.conf
[volume] action=delete volname=10.70.46.13:glustervol
gdeploy -c txt.conf
[hosts] 10.0.0.1 10.0.0.2
[devices] /dev/sda /dev/sdb
[disktype] raid6
[diskcount] 10
"Warning: We recommend a stripe unit size of 256KB for RAID 10"
[stripesize] 128
[vgs] CUSTOM_vg1 CUSTOM_vg2
[pools] CUSTOM_pool1 CUSTOM_pool2
[lvs] CUSTOM_lv1 CUSTOM_lv2
[mountpoints] /rhgs/brick1 /rhgs/brick2
[peer] action=probe
* action * hosts * fstype * client_mount_points
[clients] action=mount hosts=10.0.0.10 fstype=nfs options=vers=3 client_mount_points=/mnt/rhs
* action * volname * transport * replica * replica_count * disperse * disperse_count * redundancy_count * force
[volname] action=create volname=glustervol transport=tcp,rdma replica=yes replica_count=3 force=yes
[backend-setup] devices=sda,sdb,sdc
[backend-setup] devices=sdb,sdc,sdd,sde dalign=256k
[backend-setup] devices=sdb,sdc,sdd,sde dalign=1280k
[backend-setup] devices=sdb,sdc,sdd,sde dalign=1536k
pvs -o +pe_start /dev/sdb PV VG Fmt Attr PSize PFree 1st PE /dev/sdb lvm2 a-- 9.09t 9.09t 1.25m
[backend-setup] devices=sda,sdb,sdc vgs=custom_vg1,custom_vg2,custom_vg3
[backend-setup] devices=sda,sdb,sdc vgs=custom_vg{1..3}
[backend-setup] devices=sda,sdb,sdc vgs=custom_vg1,custom_vg2,custom_vg3 pools=custom_pool1,custom_pool2,custom_pool3
[backend-setup] devices=sda,sdb,sdc vgs=custom_vg1,custom_vg2,custom_vg3 pools=custom_pool1,custom_pool2,custom_pool3 lvs=custom_lv1,custom_lv2,custom_lv3
[backend-setup] devices=sda,sdb,sdc vgs=custom_vg1,custom_vg2,custom_vg3 pools=custom_pool1,custom_pool2,custom_pool3 lvs=custom_lv1,custom_lv2,custom_lv3 mountpoints=/gluster/data1,/gluster/data2,/gluster/data3
[backend-setup] ssd=sdc vgs=RHS_vg1 datalv=lv_data cachedatalv=lv_cachedata:1G cachemetalv=lv_cachemeta:230G
[pv] action=create devices=vdb,vdc,vdd
[pv:10.0.5.2] action=create devices=vdb,vdc,vdd
[pv] action=resize devices=vdb expand=yes
[pv] action=resize devices=vdb shrink=100G
[pv] action=create devices=sdb,sdc,sdd,sde dalign=256k
[pv] action=create devices=sdb,sdc,sdd,sde dalign=1280k
[pv] action=create devices=sdb,sdc,sdd,sde dalign=1536k
pvs -o +pe_start /dev/sdb PV VG Fmt Attr PSize PFree 1st PE /dev/sdb lvm2 a-- 9.09t 9.09t 1.25m
[vg] action=create vgname=images_vg pvname=sdb,sdc
[vg] action=create vgname=rhgs_vg pvname=sdb,sdc one-to-one=yes
[vg] action=extend vgname=rhgs_images pvname=sdc
[lv] action=create vgname=RHGS_vg1 poolname=lvthinpool lvtype=thinpool poolmetadatasize=200MB chunksize=1024k size=30GB
[lv] action=create vgname=RHGS_vg1 lvname=engine_lv lvtype=thick size=10GB mount=/rhgs/brick1
[RH-subscription1] action=register username=qa@redhat.com password=<passwd> pool=<pool> ignore_register_errors=no
[RH-subscription2] action=disable-repos repos=*
[RH-subscription3] action=enable-repos repos=rhel-7-server-rpms,rh-gluster-3-for-rhel-7-server-rpms,rhel-7-server-rhev-mgmt-agent-rpms ignore_enable_errors=no
[yum1] action=install gpgcheck=no Repos should be an url; eg: http://repo-pointing-glusterfs-builds repos=<glusterfs.repo>,<vdsm.repo> packages=vdsm,vdsm-gluster,ovirt-hosted-engine-setup,screen,xauth update=yes
[yum2:host1] action=install gpgcheck=no packages=rhevm-appliance
[shell] action=execute command=vdsm-tool configure --force
[update-file] action=copy src=/tmp/foo.cfg
[update-file] action=edit replace=allowed_hosts line=allowed_hosts=host.redhat.com
[update-file] action=add dest=/etc/ntp.conf line=server clock.redhat.com iburst
[update-file] action=add dest=/etc/chrony.conf line=server 0.rhel.pool.ntp.org iburst
[service1] action=enable service=ntpd
[service2] action=restart service=ntpd
[service1] action=enable service=chrony
[service2] action=restart service=chrony
[script] action=execute file=/usr/share/ansible/gdeploy/scripts/disable-multipath.sh
[firewalld] action=add ports=111/tcp,2049/tcp,54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,16514/tcp services=glusterfs
Master_HostName : Master_VolName
Slave_HostName : Slave_VolName
Slave1_IPAddress , Slave2_IPAddress
[geo-replication] action=create georepuser=testgeorep mastervol=10.1.1.29:mastervolume slavevol=10.1.1.25:slavevolume slavenodes=10.1.1.28,10.1.1.86 force=yes start=yes
[RH-subscription1] action=register username=<user>@redhat.com password=<password> pool=<pool-id>
gdeploy -c txt.conf
[RH-subscription2] action=enable-repos repos=rhel-7-server-rpms,rh-gluster-3-for-rhel-7-server-rpms,rh-gluster-3-nfs-for-rhel-7-server-rpms,rhel-ha-for-rhel-7-server-rpms,rhel-7-server-ansible-2-rpms
gdeploy -c txt.conf
[firewalld] action=add ports=111/tcp,2049/tcp,54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,16514/tcp services=glusterfs,nlm,nfs,rpc-bind,high-availability,mountd,rquota
gdeploy -c txt.conf
[yum] action=install repolist= gpgcheck=no update=no packages=glusterfs-ganesha
gdeploy -c txt.conf
[hosts] host-1.example.com host-2.example.com host-3.example.com host-4.example.com [backend-setup] devices=/dev/vdb vgs=vg1 pools=pool1 lvs=lv1 mountpoints=/mnt/brick [firewalld] action=add ports=111/tcp,2049/tcp,54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,16514/tcp,662/tcp,662/udp services=glusterfs,nlm,nfs,rpc-bind,high-availability,mountd,rquota [volume] action=create volname=ganesha transport=tcp replica_count=3 force=yes #Creating a high availability cluster and exporting the volume [nfs-ganesha] action=create-cluster ha-name=ganesha-ha-360 cluster-nodes=host-1.example.com,host-2.example.com,host-3.example.com,host-4 .example.com vip=10.70.44.121,10.70.44.122 volname=ganesha ignore_ganesha_errors=no
gdeploy -c txt.conf
[hosts] host-1.example.com host-2.example.com To destroy the high availability cluster [nfs-ganesha] action=destroy-cluster cluster-nodes=host-1.example.com,host-2.example.com
gdeploy -c txt.conf
[hosts] host-1.example.com host-2.example.com host-3.example.com [peer] action=probe [clients] action=mount volname=host-3.example.com:gluster_shared_storage hosts=host-3.example.com fstype=glusterfs client_mount_points=/var/run/gluster/shared_storage/ [nfs-ganesha] action=add-node nodes=host-3.example.com cluster_nodes=host-1.example.com,host-2.example.com vip=10.0.0.33
gdeploy -c txt.conf
[hosts] host-1.example.com host-2.example.com host-3.example.com host-4.example.com [nfs-ganesha] action=delete-node nodes=host-2.example.com
[hosts] host-1.example.com host-2.example.com [nfs-ganesha] action=export-volume volname=ganesha
gdeploy -c txt.conf
[hosts] host-1.example.com host-2.example.com [nfs-ganesha] action=unexport-volume volname=ganesha
gdeploy -c txt.conf
[hosts] host1-example.com host2-example.com [nfs-ganesha] action=refresh-config Default block name is `client' block-name=client config-block=clients = 10.0.0.1;|allow_root_access = true;|access_type = "RO";|Protocols = "2", "3";|anonymous_uid = 1440;|anonymous_gid = 72; volname=ganesha
gdeploy -c txt.conf
[hosts] host1-example.com host2-example.com [nfs-ganesha] action=refresh-config del-config-lines=client volname=ganesha
gdeploy -c txt.conf
[hosts] host1-example.com host2-example.com [nfs-ganesha] action=refresh-config volname=ganesha
gdeploy -c txt.conf
[hosts] host1-example.com host2-example.com [nfs-ganesha] action=refresh-config update_config_lines=Access_type = "RO"; #update_config_lines=Protocols = "4"; #update_config_lines=clients = 10.0.0.1; volname=ganesha
gdeploy -c txt.conf
[RH-subscription1] action=register username=<user>@redhat.com password=<password> pool=<pool-id>
gdeploy -c txt.conf
[RH-subscription2] action=enable-repos repos=rhel-7-server-rpms,rh-gluster-3-for-rhel-7-server-rpms,rh-gluster-3-samba-for-rhel-7-server-rpms,rhel-7-server-ansible-2-rpms
[RH-subscription2] action=enable-repos rh-gluster-3-for-rhel-8-x86_64-rpms,ansible-2-for-rhel-8-x86_64-rpms,rhel-8-for-x86_64-baseos-rpms,rhel-8-for-x86_64-appstream-rpms,rhel-8-for-x86_64-highavailability-rpms,rh-gluster-3-samba-for-rhel-8-x86_64-rpms
gdeploy -c txt.conf
[firewalld] action=add ports=54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,4379/tcp services=glusterfs,samba,high-availability
gdeploy -c txt.conf
[yum] action=install repolist= gpgcheck=no update=no packages=samba,samba-client,glusterfs-server,ctdb
gdeploy -c txt.conf
[hosts] 10.70.37.192 10.70.37.88 [volume] action=smb-setup volname=samba1 force=yes smb_username=smbuser smb_mountpoint=/mnt/smb
gdeploy -c txt.conf
[hosts] 10.70.37.192 10.70.37.88 10.70.37.65 [backend-setup] devices=/dev/vdb vgs=vg1 pools=pool1 lvs=lv1 mountpoints=/mnt/brick [volume] action=create volname=samba1 smb=yes force=yes smb_username=smbuser smb_mountpoint=/mnt/smb
gdeploy -c txt.conf
[hosts] 10.70.37.192 10.70.37.88 10.70.37.65 [volume] action=create volname=ctdb transport=tcp replica_count=3 force=yes [ctdb] action=setup public_address=10.70.37.6/24 eth0,10.70.37.8/24 eth0 volname=ctdb
[hosts] 10.70.37.192 10.70.37.88 10.70.37.65 [volume] action=create volname=ctdb transport=tcp replica_count=3 force=yes [ctdb] action=setup public_address=10.70.37.6/24 eth0,10.70.37.8/24 eth0 ctdb_nodes=192.168.1.1,192.168.2.5 volname=ctdb
gdeploy -c txt.conf
[hosts] 10.70.37.147 10.70.37.47 10.70.37.13 [backend-setup] devices=/dev/vdb vgs=vg1 pools=pool1 lvs=lv1 mountpoints=/mnt/brick [volume] action=create volname=vol1 transport=tcp replica_count=3 force=yes enable_ssl=yes ssl_clients=10.70.37.107,10.70.37.173 brick_dirs=/data/1 [clients] action=mount hosts=10.70.37.173,10.70.37.107 volname=vol1 fstype=glusterfs client_mount_points=/mnt/data
gdeploy -c txt.conf
[hosts] 10.70.37.147 10.70.37.47 It is important for the clients to be unmounted before setting up SSL [clients1] action=unmount hosts=10.70.37.173,10.70.37.107 client_mount_points=/mnt/data [volume] action=enable-ssl volname=vol2 ssl_clients=10.70.37.107,10.70.37.173 [clients2] action=mount hosts=10.70.37.173,10.70.37.107 volname=vol2 fstype=glusterfs client_mount_points=/mnt/data
gdeploy -c txt.conf
export GDEPLOY_LOGFILE=/var/log/gdeploy/gdeploy.log