Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

此内容没有您所选择的语言版本。

7.2. In-Service Software Upgrade from Red Hat Gluster Storage 3.3 to Red Hat Gluster Storage 3.4

Important

Upgrade all Red Hat Gluster Storage servers before updating clients.
In-service software upgrade refers to the ability to progressively update a Red Hat Gluster Storage Server cluster with a new version of the software without taking the volumes hosted on the cluster offline. In most cases normal I/O operations on the volume continue even when the cluster is being updated.
I/O that uses CTDB may pause for the duration of an upgrade or update. This affects clients using Gluster NFS or Samba.

Note

After performing inservice upgrade of NFS-Ganesha, the new configuration file is saved as "ganesha.conf.rpmnew" in /etc/ganesha folder. The old configuration file is not overwritten during the inservice upgrade process. However, post upgradation, you have to manually copy any new configuration changes from "ganesha.conf.rpmnew" to the existing ganesha.conf file in /etc/ganesha folder.

7.2.1. Pre-upgrade Tasks
复制链接

Ensure you perform the following steps based on the set-up before proceeding with the in-service software upgrade process.
The following are the upgrade requirements to upgrade to Red Hat Gluster Storage 3.4 from the preceding update:
  • In-service software upgrade is supported only for nodes with replicate, distributed replicate, or erasure coded (dispersed) volumes.
  • If you want to use snapshots for your existing environment, each brick must be an independent thin provisioned logical volume (LV). If you do not plan to use snapshots, thickly provisioned volumes remain supported.
  • A Logical Volume that contains a brick must not be used for any other purpose.
  • Only linear LVM is supported with Red Hat Gluster Storage 3.4. For more information, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Logical_Volume_Manager_Administration/lv_overview.html#linear_volumes
  • When server-side quorum is enabled, ensure that bringing one node down does not violate server-side quorum. Add dummy peers to ensure the server-side quorum is not violated until the completion of rolling upgrade using the following command: 
    # gluster peer probe dummynode
    Copy to Clipboard Toggle word wrap

    Note

    If you have a geo-replication session, then to add a node follow the steps mentioned in the sectionStarting Geo-replication for a New Brick or New Node in the Red Hat Gluster Storage Administration Guide.
    For example, when the server-side quorum percentage is set to the default value (>50%), for a plain replicate volume with two nodes and one brick on each machine, a dummy node that does not contain any bricks must be added to the trusted storage pool to provide high availability of the volume using the command mentioned above.
    In a three node cluster, if the server-side quorum percentage is set to 77%, bringing down one node would violate the server-side quorum. In this scenario, you have to add two dummy nodes to meet server-side quorum.
  • For replica 2 volumes, disable client-side quorum. This is not recommended for replica 3 volumes, as it increases the risk of split brain conditions developing. 
    # gluster volume reset <vol-name> cluster.quorum-type
    Copy to Clipboard Toggle word wrap
  • Stop any geo-replication sessions running between the master and slave. 
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop
    Copy to Clipboard Toggle word wrap
  • Ensure that there are no pending self-heals before proceeding with in-service software upgrade using the following command: 
    # gluster volume heal volname info
    Copy to Clipboard Toggle word wrap
  • Ensure the Red Hat Gluster Storage server is registered to the required channels.
    On Red Hat Enterprise Linux 6: 
    rhel-x86_64-server-6
rhel-x86_64-server-6-rhs-3
rhel-x86_64-server-sfs-6
    Copy to Clipboard Toggle word wrap
    On Red Hat Enterprise Linux 7: 
    rhel-x86_64-server-7
rhel-x86_64-server-7-rhs-3
rhel-x86_64-server-sfs-7
    Copy to Clipboard Toggle word wrap
    To subscribe to the channels, run the following command: 
    # subscription-manager repos --enable=repo-name
    Copy to Clipboard Toggle word wrap

7.2.1.2. Restrictions for In-Service Software Upgrade
复制链接

The following lists some of the restrictions for in-service software upgrade:
  • In-service upgrade for NFS-Ganesha clusters is supported only from Red Hat Gluster Storage 3.3 to Red Hat Gluster Storage 3.4. If you are upgrading from Red Hat Gluster Storage 3.1 and you use NFS-Ganesha, use the offline upgrade method instead.
  • Erasure coded (dispersed) volumes can be upgraded while in-service only if the disperse.optimistic-change-log and disperse.eager-lock options are set to off. Wait for at least two minutes after disabling these options before attempting to upgrade to ensure that these configuration changes take effect for I/O operations.
  • Ensure that the system workload is low before performing the in-service software upgrade, so that the self-heal process does not have to heal too many entries during the upgrade. Also, with high system workload healing is time-consuming.
  • Do not perform any volume operations on the Red Hat Gluster Storage server.
  • Do not change hardware configurations.
  • Do not run mixed versions of Red Hat Gluster Storage for an extended period of time. For example, do not have a mixed environment of Red Hat Gluster Storage 3.3 and Red Hat Gluster Storage 3.4 for a prolonged time.
  • Do not combine different upgrade methods.
  • It is not recommended to use in-service software upgrade for migrating to thin provisioned volumes, but to use offline upgrade scenario instead. For more information see, Section 7.1, “Offline Upgrade to Red Hat Gluster Storage 3.4”

7.2.1.3. Configuring repo for Upgrading using ISO
复制链接

To configure the repo to upgrade using ISO, execute the following steps:

Note

Upgrading Red Hat Gluster Storage using ISO can be performed only from the immediately preceding release. This means that upgrading to Red Hat Gluster Storage 3.4 using ISO can only be done from Red Hat Gluster Storage 3.3.1. For a complete list of supported Red Hat Gluster Storage releases, see Section 1.5, “Supported Versions of Red Hat Gluster Storage”.
  1. Mount the ISO image file under any directory using the following command: 
    # mount -o loop <ISO image file> <mount-point>
    Copy to Clipboard Toggle word wrap
    For example: 
    # mount -o loop RHGS-3.4-RHEL-7-x86_64-dvd-1.iso /mnt
    Copy to Clipboard Toggle word wrap
  2. Set the repo options in a file in the following location: 
     /etc/yum.repos.d/<file_name.repo>
    Copy to Clipboard Toggle word wrap
  3. Add the following information to the repo file: 
    [local]
name=local
baseurl=file:///mnt
enabled=1
gpgcheck=0
    Copy to Clipboard Toggle word wrap

7.2.1.4. Preparing and Monitoring the Upgrade Activity
复制链接

Before proceeding with the in-service software upgrade, prepare and monitor the following processes:
  • Check the peer and volume status to ensure that all peers are connected and there are no active volume tasks. 
    # gluster peer status
    Copy to Clipboard Toggle word wrap 
    # gluster volume status
    Copy to Clipboard Toggle word wrap
  • Check the rebalance status using the following command: 
    # gluster volume rebalance r2 status
Node   Rebalanced-files  size      scanned   failures    skipped   status   run time in secs
---------   -----------    ---------   --------   ---------  ------  --------  --------------
10.70.43.198         0       0Bytes       99       0           0    completed     1.00
10.70.43.148         49      196Bytes    100       0           0    completed     3.00
    Copy to Clipboard Toggle word wrap
  • If you need to upgrade an erasure coded (dispersed) volume, set the disperse.optimistic-change-log and disperse.eager-lock options to off. Wait for at least two minutes after disabling these options before attempting to upgrade to ensure that these configuration changes take effect for I/O operations. 
    # gluster volume set volname disperse.optimistic-change-log off
# gluster volume set volname disperse.eager-lock off
    Copy to Clipboard Toggle word wrap
  • Ensure that there are no pending self-heals by using the following command: 
    # gluster volume heal volname info
    Copy to Clipboard Toggle word wrap
    The following example shows no pending self-heals. 
    # gluster volume heal drvol info
Gathering list of entries to be healed on volume drvol has been successful

Brick 10.70.37.51:/rhs/brick1/dir1
Number of entries: 0

Brick 10.70.37.78:/rhs/brick1/dir1
Number of entries: 0

Brick 10.70.37.51:/rhs/brick2/dir2
Number of entries: 0

Brick 10.70.37.78:/rhs/brick2/dir2
Number of entries: 0
    Copy to Clipboard Toggle word wrap

7.2.2. Service Impact of In-Service Upgrade
复制链接

In-service software upgrade impacts the following services. Ensure you take the required precautionary measures.
SWIFT

ReST requests that are in transition will fail during in-service software upgrade. Hence it is recommended to stop all swift services before in-service software upgrade using the following commands: 

# service openstack-swift-proxy stop
# service openstack-swift-account stop
# service openstack-swift-container stop
# service openstack-swift-object stop
Copy to Clipboard Toggle word wrap
Gluster NFS

When you use Gluster NFS to mount a volume, any new or outstanding file operations on that file system will hang uninterruptedly during in-service software upgrade until the server is upgraded.

Samba / CTDB

Ongoing I/O on Samba shares will fail as the Samba shares will be temporarily unavailable during the in-service software upgrade, hence it is recommended to stop the Samba service using the following command: 

# service ctdb stop   ;Stopping CTDB will also stop the SMB service.
Copy to Clipboard Toggle word wrap

Distribute Volume

In-service software upgrade is not supported for distributed volume. If you have a distributed volume in the cluster, stop that volume for the duration of the upgrade. 

# gluster volume stop <VOLNAME>
Copy to Clipboard Toggle word wrap
Virtual Machine Store

The virtual machine images are likely to be modified constantly. The virtual machine listed in the output of the volume heal command does not imply that the self-heal of the virtual machine is incomplete. It could mean that the modifications on the virtual machine are happening constantly.

Hence, if you are using a gluster volume for storing virtual machine images (Red Hat Enterprise Linux, Red Hat Enterprise Virtualization and Red Hat OpenStack), then it is recommended to power-off all virtual machine instances before in-service software upgrade.

Important

It is recommended to turn off all virtual machine instances to minimize the changes that occur during an In-Service Upgrade. If you choose to keep the VM instances up and running , the time taken to heal will increase and at times may cause a situation where the pending heal remains a constant number and takes a long time to close to 0.

7.2.3. In-Service Software Upgrade
复制链接

If you have a CTDB environment, see Section 7.2.4.1, “In-Service Software Upgrade for a CTDB Setup”.
The following steps have to be performed on each node of the replica pair:
  1. Back up the following configuration directory and files in a location that is not on the operating system partition.
    • /var/lib/glusterd
    • /etc/swift
    • /etc/samba
    • /etc/ctdb
    • /etc/glusterfs
    • /var/lib/samba
    • /var/lib/ctdb
    • /var/run/gluster/shared_storage/nfs-ganesha
    If you use NFS-Ganesha, back up the following files from all nodes:
    • /etc/ganesha/exports/export.*.conf
    • /etc/ganesha/ganesha.conf
    • /etc/ganesha/ganesha-ha.conf
  2. If the node is part of an NFS-Ganesha cluster, place the node in standby mode. 
    # pcs cluster standby
    Copy to Clipboard Toggle word wrap
  3. Ensure that there are no pending self-heal operations. 
    # gluster volume heal volname info
    Copy to Clipboard Toggle word wrap
  4. If this node is part of an NFS-Ganesha cluster:
    1. Disable the PCS cluster and verify that it has stopped. 
      # pcs cluster disable
# pcs status
      Copy to Clipboard Toggle word wrap
    2. Stop the nfs-ganesha service. 
      # systemctl stop nfs-ganesha
      Copy to Clipboard Toggle word wrap
  5. Stop all gluster services on the node and verify that they have stopped. 
    # systemctl stop glusterd
# pkill glusterfs
# pkill glusterfsd
# pgrep gluster
    Copy to Clipboard Toggle word wrap
  6. Verify that your system is not using the legacy Red Hat Classic update software. 
    # migrate-rhs-classic-to-rhsm --status
    Copy to Clipboard Toggle word wrap
    If your system uses this legacy software, migrate to Red Hat Subscription Manager and verify that your status has changed when migration is complete. 
    # migrate-rhs-classic-to-rhsm --rhn-to-rhsm
    Copy to Clipboard Toggle word wrap 
    # migrate-rhs-classic-to-rhsm --status
    Copy to Clipboard Toggle word wrap
  7. Update the server using the following command: 
    # yum update
    Copy to Clipboard Toggle word wrap
  8. If the volumes are thick provisioned, and you plan to use snapshots, perform the following steps to migrate to thin provisioned volumes:

    Note

    Migrating from thick provisioned volume to thin provisioned volume during in-service software upgrade takes a significant amount of time based on the data you have in the bricks. If you do not plan to use snapshots, you can skip this step. However, if you plan to use snapshots on your existing environment, the offline method to upgrade is recommended. For more information regarding offline upgrade, see Section 7.1, “Offline Upgrade to Red Hat Gluster Storage 3.4”
    Contact a Red Hat Support representative before migrating from thick provisioned volumes to thin provisioned volumes using in-service software upgrade.
    1. Unmount all the bricks associated with the volume by executing the following command: 
      # umount mount_point
      Copy to Clipboard Toggle word wrap
    2. Remove the LVM associated with the brick by executing the following command: 
      # lvremove logical_volume_name
      Copy to Clipboard Toggle word wrap
      For example: 
      # lvremove /dev/RHS_vg/brick1
      Copy to Clipboard Toggle word wrap
    3. Remove the volume group by executing the following command: 
      # vgremove -ff volume_group_name
      Copy to Clipboard Toggle word wrap
      For example: 
      # vgremove -ff RHS_vg
      Copy to Clipboard Toggle word wrap
    4. Remove the physical volume by executing the following command: 
      # pvremove -ff physical_volume
      Copy to Clipboard Toggle word wrap
    5. If the physical volume (PV) is not created, then create the PV for a RAID 6 volume by executing the following command, else proceed with the next step: 
      # pvcreate --dataalignment 2560K /dev/vdb
      Copy to Clipboard Toggle word wrap
      For more information, see the Red Hat Gluster Storage 3.4 Administration Guide: https://access.redhat.com/documentation/en-us/red_hat_gluster_Storage/3.4/html-single/administration_guide/#Formatting_and_Mounting_Bricks.
    6. Create a single volume group from the PV by executing the following command: 
      # vgcreate volume_group_name disk
      Copy to Clipboard Toggle word wrap
      For example: 
      # vgcreate RHS_vg /dev/vdb
      Copy to Clipboard Toggle word wrap
    7. Create a thinpool using the following command: 
      # lvcreate -L size --poolmetadatasize md_size --chunksize chunk_size -T pool_device
      Copy to Clipboard Toggle word wrap
      For example: 
      # lvcreate -L 2T --poolmetadatasize 16G --chunksize 256  -T /dev/RHS_vg/thin_pool
      Copy to Clipboard Toggle word wrap
    8. Create a thin volume from the pool by executing the following command: 
      # lvcreate -V size -T pool_device -n thinvol_name
      Copy to Clipboard Toggle word wrap
      For example: 
      # lvcreate -V 1.5T -T /dev/RHS_vg/thin_pool -n thin_vol
      Copy to Clipboard Toggle word wrap
    9. Create filesystem in the new volume by executing the following command: 
      # mkfs.xfs -i size=512 thin_vol
      Copy to Clipboard Toggle word wrap
      For example: 
      # mkfs.xfs -i size=512 /dev/RHS_vg/thin_vol
      Copy to Clipboard Toggle word wrap
      The back-end is now converted to a thin provisioned volume.
    10. Mount the thin provisioned volume to the brick directory and setup the extended attributes on the bricks. For example: 
      # setfattr -n trusted.glusterfs.volume-id \ -v 0x$(grep volume-id /var/lib/glusterd/vols/volname/info \ | cut -d= -f2 | sed 's/-//g') $brick
      Copy to Clipboard Toggle word wrap
  9. Disable glusterd. 
    # systemctl disable glusterd
    Copy to Clipboard Toggle word wrap
    This prevents it starting during boot time, so that you can ensure the node is healthy before it rejoins the cluster.
  10. Reboot the server. 
    # shutdown -r now "Shutting down for upgrade to Red Hat Gluster Storage 3.4"
    Copy to Clipboard Toggle word wrap

  11. Important

    Perform this step only for each thick provisioned volume that has been migrated to thin provisioned volume in the previous step.
    Change the Automatic File Replication extended attributes from another node, so that the heal process is executed from a brick in the replica subvolume to the thin provisioned brick.
    1. Create a FUSE mount point to edit the extended attributes. 
      # mount -t glusterfs HOSTNAME_or_IPADDRESS:/VOLNAME /MOUNTDIR
      Copy to Clipboard Toggle word wrap
    2. Create a new directory on the mount point, and ensure that a directory with such a name is not already present. 
      # mkdir /MOUNTDIR/name-of-nonexistent-dir
      Copy to Clipboard Toggle word wrap
    3. Delete the directory and set the extended attributes. 
      # rmdir /MOUNTDIR/name-of-nonexistent-dir
      Copy to Clipboard Toggle word wrap 
      # setfattr -n trusted.non-existent-key -v abc /MOUNTDIR
# setfattr -x trusted.non-existent-key /MOUNTDIR
      Copy to Clipboard Toggle word wrap
    4. Ensure that the extended attributes of the brick in the replica subvolume is not set to zero. 
      # getfattr -d -m. -e hex brick_path
      Copy to Clipboard Toggle word wrap
      In the following example, the extended attribute trusted.afr.repl3-client-1 for /dev/RHS_vg/brick2 is not set to zero: 
      # getfattr -d -m. -e hex /dev/RHS_vg/brick2
getfattr: Removing leading '/' from absolute path names
# file: /dev/RHS_vg/brick2
trusted.afr.dirty=0x000000000000000000000000
trusted.afr.repl3-client-1=0x000000000000000400000002
trusted.gfid=0x00000000000000000000000000000001
trusted.glusterfs.dht=0x000000010000000000000000ffffffff
trusted.glusterfs.volume-id=0x924c2e2640d044a687e2c370d58abec9
      Copy to Clipboard Toggle word wrap
  12. Start the glusterd service. 
    # systemctl start glusterd
    Copy to Clipboard Toggle word wrap
  13. Verify that you have upgraded to the latest version of Red Hat Gluster Storage. 
    # gluster --version
    Copy to Clipboard Toggle word wrap
  14. Ensure that all bricks are online. 
    # gluster volume status
    Copy to Clipboard Toggle word wrap
    For example: 
    # gluster volume status
Status of volume: r2

Gluster process                                         Port    Online  Pid
------------------------------------------------------------------------------
Brick 10.70.43.198:/brick/r2_0                          49152   Y       32259
Brick 10.70.42.237:/brick/r2_1                          49152   Y       25266
Brick 10.70.43.148:/brick/r2_2                          49154   Y       2857
Brick 10.70.43.198:/brick/r2_3                          49153   Y       32270
NFS Server on localhost                                 2049    Y       25280
Self-heal Daemon on localhost                           N/A     Y       25284
NFS Server on 10.70.43.148                              2049    Y       2871
Self-heal Daemon on 10.70.43.148                        N/A     Y       2875
NFS Server on 10.70.43.198                              2049    Y       32284
Self-heal Daemon on 10.70.43.198                        N/A     Y       32288

Task Status of Volume r2
------------------------------------------------------------------------------
There are no active volume tasks
    Copy to Clipboard Toggle word wrap
  15. Start self-heal on the volume. 
    # gluster volume heal volname
    Copy to Clipboard Toggle word wrap
  16. Ensure that self-heal on the volume is complete. 
    # gluster volume heal volname info
    Copy to Clipboard Toggle word wrap
    The following example shows a completed self heal operation. 
     # gluster volume heal drvol info
Gathering list of entries to be healed on volume drvol has been successful

Brick 10.70.37.51:/rhs/brick1/dir1
Number of entries: 0

Brick 10.70.37.78:/rhs/brick1/dir1
Number of entries: 0

Brick 10.70.37.51:/rhs/brick2/dir2
Number of entries: 0

Brick 10.70.37.78:/rhs/brick2/dir2
Number of entries: 0
    Copy to Clipboard Toggle word wrap
  17. Verify that shared storage is mounted. 
    # mount | grep /run/gluster/shared_storage
    Copy to Clipboard Toggle word wrap
  18. If this node is part of an NFS-Ganesha cluster:
    1. If the system is managed by SELinux, set the ganesha_use_fusefs Boolean to on. 
      # setsebool -P ganesha_use_fusefs on
      Copy to Clipboard Toggle word wrap
    2. Start the NFS-Ganesha service. 
      # systemctl start nfs-ganesha
      Copy to Clipboard Toggle word wrap
    3. Enable and start the cluster. 
      # pcs cluster enable
# pcs cluster start
      Copy to Clipboard Toggle word wrap
    4. Release the node from standby mode. 
      # pcs cluster unstandby
      Copy to Clipboard Toggle word wrap
    5. Verify that the pcs cluster is running, and that the volume is being exported correctly after upgrade. 
      # pcs status
# showmount -e
      Copy to Clipboard Toggle word wrap
      NFS-ganesha enters a short grace period after performing these steps. I/O operations halt during this grace period. Wait until you see NFS Server Now NOT IN GRACE in the ganesha.log file before continuing.
  19. Optionally, enable the glusterd service to start at boot time. 
    # systemctl enable glusterd
    Copy to Clipboard Toggle word wrap
  20. Repeat the above steps on the other node of the replica pair. In the case of a distributed-replicate setup, repeat the above steps on all the replica pairs.
  21. When all nodes have been upgraded, run the following command to update the op-version of the cluster. This helps to prevent any compatibility issues within the cluster. 
     # gluster volume set all cluster.op-version 31306
    Copy to Clipboard Toggle word wrap

    Note

    31306 is the cluster.op-version value for Red Hat Gluster Storage 3.4 Async Update. Refer to Section 1.5, “Supported Versions of Red Hat Gluster Storage” for the correct cluster.op-version value for other versions.

    Note

    If you want to enable snapshots, see the Red Hat Gluster Storage 3.4 Administration Guide: https://access.redhat.com/documentation/en-us/red_hat_gluster_Storage/3.4/html-single/administration_guide/#Troubleshooting1.
  22. If the client-side quorum was disabled before upgrade, then upgrade it by executing the following command: 
    # gluster volume set volname cluster.quorum-type auto
    Copy to Clipboard Toggle word wrap
  23. If a dummy node was created earlier, then detach it by executing the following command: 
    # gluster peer detach <dummy_node name>
    Copy to Clipboard Toggle word wrap
  24. If the geo-replication session between master and slave was disabled before upgrade, then configure the meta volume and restart the session: 
    # gluster volume set all cluster.enable-shared-storage enable
    Copy to Clipboard Toggle word wrap 
    # gluster volume geo-replication Volume1 example.com::slave-vol config use_meta_volume true
    Copy to Clipboard Toggle word wrap 
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start
    Copy to Clipboard Toggle word wrap
  25. If you disabled the disperse.optimistic-change-log and disperse.eager-lock options in order to upgrade an erasure-coded (dispersed) volume, re-enable these settings. 
    # gluster volume set volname disperse.optimistic-change-log on
# gluster volume set volname disperse.eager-lock on
    Copy to Clipboard Toggle word wrap
The following sections describe the in-service software upgrade steps for a CTDB setup.

7.2.4.1. In-Service Software Upgrade for a CTDB Setup
复制链接

Before you upgrade the CTDB packages, ensure you upgrade the Red Hat Gluster Storage server by following these steps. The following steps have to be performed on each node of the replica pair.
  1. To ensure that the CTDB does not start automatically after a reboot run the following command on each node of the CTDB cluster: 
    # systemctl disable ctdb
    Copy to Clipboard Toggle word wrap
  2. Stop the CTDB service on the Red Hat Gluster Storage node using the following command on each node of the CTDB cluster: 
    # systemctl stop ctdb
    Copy to Clipboard Toggle word wrap
    1. To verify if the CTDB and SMB services are stopped, execute the following command: 
      # ps axf | grep -E '(ctdb|smb|winbind|nmb)[d]'
      Copy to Clipboard Toggle word wrap
  3. Stop the gluster services on the storage server using the following commands: 
    # systemctl stop glusterd
# pkill glusterfs
# pkill glusterfsd
    Copy to Clipboard Toggle word wrap
  4. In /etc/fstab, comment out the line containing the volume used for CTDB service as shown in the following example: 
    # HostName:/volname  /gluster/lock glusterfs defaults,transport=tcp 0 0
    Copy to Clipboard Toggle word wrap
  5. Update the server using the following command: 
    # yum update
    Copy to Clipboard Toggle word wrap
  6. If SELinux support is required, then enable SELinux by following the steps mentioned in, Chapter 10, Enabling SELinux
  7. After SELinux is enabled, set the following boolean:
    For Samba

    setsebool -P samba_load_libgfapi 1

    For CTDB

    setsebool -P use_fusefs_home_dirs 1

  8. To ensure the glusterd service does not start automatically after reboot, execute the following command: 
    # systemctl disable glusterd
    Copy to Clipboard Toggle word wrap
  9. Reboot the server.
  10. Update the META=all with the gluster volume information in the following scripts: 
    /var/lib/glusterd/hooks/1/start/post/S29CTDBsetup.sh /var/lib/glusterd/hooks/1/stop/pre/S29CTDB-teardown.sh
    Copy to Clipboard Toggle word wrap
  11. In /etc/fstab, uncomment the line containing the volume used for CTDB service as shown in the following example: 
    HostName:/volname /gluster/lock glusterfs defaults,transport=tcp 0 0
    Copy to Clipboard Toggle word wrap
  12. To automatically start the glusterd daemon every time the system boots, run the following command: 
    # systemctl enable glusterd
    Copy to Clipboard Toggle word wrap
  13. To automatically start the ctdb daemon every time the system boots, run the following command: 
    # systemctl enable ctdb
    Copy to Clipboard Toggle word wrap
  14. Start the glusterd service using the following command: 
    # systemctl start glusterd
    Copy to Clipboard Toggle word wrap
  15. If using NFS to access volumes, enable gluster-NFS using below command: 
    # gluster volume set <volname> nfs.disable off
    Copy to Clipboard Toggle word wrap
    For example: 
    # gluster volume set testvol nfs.disable off
volume set: success
    Copy to Clipboard Toggle word wrap
  16. Mount the CTDB volume by running the following command: 
    # mount -a
    Copy to Clipboard Toggle word wrap
  17. Start the CTDB service using the following command: 
    # systemctl start ctdb
    Copy to Clipboard Toggle word wrap
  18. To verify if CTDB is running successfully, execute the following commands: 
    # ctdb status
# ctdb ip
# ctdb ping -n all
    Copy to Clipboard Toggle word wrap
CTDB Upgrade

After upgrading the Red Hat Gluster Storage server, upgrade the CTDB package by executing the following steps:

Note

  • Upgrading CTDB on all the nodes must be done simultaneously to avoid any data corruption.
  • The following steps have to performed only when upgrading CTDB from CTDB 1.x to CTDB 4.x.
  1. Stop the CTDB service on all the nodes of the CTDB cluster by executing the following command. Ensure it is performed on all the nodes simultaneously as two different versions of CTDB cannot run at the same time in the CTDB cluster: 
    # systemctl stop ctdb
    Copy to Clipboard Toggle word wrap
  2. Perform the following operations on all the nodes used as samba servers:
    • Remove the following soft links: 
      /etc/sysconfig/ctdb
/etc/ctdb/nodes
/etc/ctdb/public_addresses
      Copy to Clipboard Toggle word wrap
    • Copy the following files from the CTDB volume to the corresponding location by executing the following command on each node of the CTDB cluster: 
      cp /gluster/lock/nodes /etc/ctdb/nodes
cp /gluster/lock/public_addresses /etc/ctdb/public_addresses
      Copy to Clipboard Toggle word wrap
  3. Stop and delete the CTDB volume by executing the following commands on one of the nodes of the CTDB cluster: 
    # gluster volume stop volname
    Copy to Clipboard Toggle word wrap 
    # gluster volume delete volname
    Copy to Clipboard Toggle word wrap
  4. To update CTDB, execute the following command: 
    # yum update
    Copy to Clipboard Toggle word wrap
For more information about configuring CTDB on a Red Hat Gluster Storage server, see section Setting Up CTDB in the Red Hat Gluster Storage Administration Guide

7.2.4.2. Verifying In-Service Software Upgrade
复制链接

To verify if you have upgraded to the latest version of the Red Hat Gluster Storage server execute the following command: 
# gluster --version
Copy to Clipboard Toggle word wrap

7.2.4.3. Upgrading the Native Client
复制链接

All clients must use the same version of glusterfs-fuse. Red Hat strongly recommends that you upgrade servers before upgrading clients. If you are upgrading from Red Hat Gluster Storage 3.1 Update 2 or earlier, you must upgrade servers and clients simultaneously. For more information regarding upgrading native client, refer to section Upgrading Native Client in the Red Hat Gluster Storage Administration Guide.
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部