LUG - Connecting and Configuring Ceph RBD Using a Linux Client
Ceph RBD (RADOS Block Device) offers users a network block device that appears as a local disk on the system where it is connected. The block device is entirely managed by the user, who can create a file system on it and use it according to his needs.
Advantages of RBD
- Ability to resize the block device image.
- Import / export of block device images.
- Stripping and replication within the cluster.
- Capability to create read-only snapshots and restore them (for RBD level snapshots, please contact us).
- Ability to connect using a Linux or QEMU KVM client
Setting Up the RBD Client (Linux)
To connect to RBD, it is recommended to use a newer kernel version on your system, as older kernel versions have deprecated RBD connection modules, meaning not all advanced features are supported. Developers suggest using at least kernel version 5.0 or higher. However, some functionalities have been backported to the CentOS 7 core.
Ceph client version For optimal functionality, it is highly recommended to use the same version of Ceph tools as the one currently running on our clusters. Then you can set up the appropriate repositories, as outlined below.
CentOS Setup
First, install the release.asc key for the Ceph repository.
sudo rpm --import 'https://download.ceph.com/keys/release.asc'In the directory /etc/yum.repos.d/ create a text file ceph.repo and fill in the record for Ceph instruments.
[ceph]
name=Ceph packages for $basearch
baseurl=https://download.ceph.com/<contact-admin-for-current-version>/el7/$basearch
enabled=1
priority=2
gpgcheck=1
gpgkey=https://download.ceph.com/keys/release.ascSome packages from the Ceph repository also require third-party libraries for proper functioning, so add the EPEL repository.
CentOS 7
sudo yum install -y epel-releaseCentOS 8
sudo dnf install -y epel-releaseRedHat 7
sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpmFinally, install the basic tools for Ceph which also include RBD support.
CentOS 7
sudo yum install ceph-commonOn CentOS 8
sudo dnf install ceph-commonUbuntu/Debian Setup
Ubuntu/Ceph includes all necessary packages natively, so you can just run following command:
sudo apt install cephRBD Configuration and Mapping
To configure and connect to RBD, use the credentials provided by the system administrator. The necessary details are as follows:
- pool name: rbd_vo_poolname
- image name: vo_name_username
- keyring: [client.rbd_user] key = key_hash ==
In the directory /etc/ceph/ create a text file ceph.conf with the following content.
LUG Data Storage
[global]
fsid = 3d8d9fd1-418a-4b13-b3d6-a437c9294ebf
mon_host = [v2:195.113.231.135:3300/0,v1:195.113.231.135:6789/0] [v2:195.113.231.136:3300/0,v1:195.113.231.136:6789/0] [v2:195.113.231.137:3300/0,v1:195.113.231.137:6789/0]
auth_client_required = cephx Next, in the /etc/ceph/ directory, create a text file ceph.keyring. Then, save the keyring in that file, as shown in the example below.
[client.rbd_user]
key = sdsaetdfrterp+sfsdM3iKY5teisfsdXoZ5==Now RBD mapping can be performed (rbd_user is a string originating from the keyring, after stripping the string client.
sudo rbd --id rbd_user --exclusive device map name_pool/name_imageWe strongly recommend using the --exclusive option when mapping the RBD image. This option prevents the image from being mapped to multiple devices or mapped multiple times locally, which could lead to data corruption. Please be aware that if there is any risk of multiple mapping, you should use the --exclusive option.
However, do not use the —exclusive option if you need to mount the RBD image on multiple machines—for example, in a clustered file system setup.
If the files ceph.conf and username.keyring are located in a directory other than the default /etc/ceph/, you must specify the corresponding paths during the mapping process. See the example below.
sudo rbd -c /home/username/ceph/ceph.conf -k /home/username/ceph/username.keyring --id rbd_user --exclusive device map name_pool/name_imageNext, check the connection in kernel messages.
dmesgNow, check the RBD status.
sudo rbd device list | grep "name_image"Encrypting and Creating a Filesystem
The next step is to encrypt the mapped image use cryptsetup-luks.
sudo yum install cryptsetup-luksThen, it encrypts the device.
sudo cryptsetup -s 512 luksFormat --type luks2 /dev/rbdXFinally, check the settings.
sudo cryptsetup luksDump /dev/rbdXTo perform further actions on an encrypted device, it must be decrypted first.
sudo cryptsetup luksOpen /dev/rbdX luks_rbdXWe recommend using XFS instead of EXT4 for larger images or those they may need to exceed 200TB over time, as EXT4 has a limit on the number of inodes.
Now, create file system on the device, here is an example xfs.
sudo mkfs.xfs -K /dev/mapper/luks_rbdXIf you use XFS, do not use the nobarrier option while mounting, it could cause data loss!
Once the file system is ready, we can mount the device to a pre-created folder in /mnt/.
sudo mount /dev/mapper/luks_rbdX /mnt/rbdEnding the Work with RBD
Unmount the volume.
sudo umount /mnt/rbd/Close the encrypted volume.
sudo cryptsetup luksClose /dev/mapper/luks_rbdXVolume unmapping.
sudo rbd --id rbd_user device unmap /dev/rbdX/To optimize performance, choose an appropriate size for the read_ahead cache based on your system´s memory size.
Example for 8GB:
echo 8388608 > /sys/block/rbd0/queue/read_ahead_kbExample for 512MB:
echo 524288 > /sys/block/rbd0/queue/read_ahead_kbTo apply the changes, you need to unmap the image and then map it again.
The method described above is not persistent (it will not survive a reboot). To make it persistent, you must add the following line to the “/etc/udev/rules.d/50-read-ahead-kb.rules” file.
You can configure specific kernel parameters for a subset of block devices (Ceph RBD)
KERNEL=="rbd[0-9]*", ENV{DEVTYPE}=="disk", ACTION=="add|change", ATTR{bdi/read_ahead_kb}="524288"Permanently Mapping RBD
Configuration for automatic RBD connection, including LUKS encryption and filesystem mounting, along with proper disconnection (in reverse order) when the machine is switched off in a controlled manner.
RBD Image
Edit the configuration file located at /etc/ceph/rbdmap by adding the following lines.
# RbdDevice Parameters
#poolname/imagename id=client,keyring=/etc/ceph/ceph.client.keyring
pool_name/image_name id=rbd_user,keyring=/etc/ceph/ceph.keyringLUKS
Edit configuration file located at /etc/crypttab by adding the following lines.
rbd_luks_pool /dev/rbd/pool_name/image_name /etc/ceph/luks.keyfile luks,_netdevwhere /etc/ceph/luks.keyfile is a LUKS key.
Path to block device source device is generally /dev/rbd/$POOL/$IMAGE
fstab file
Edit the configuration file located at /etc/fstab by adding the following lines.
/dev/mapper/rbd_luks_pool /mnt/rbd_luks_pool btrfs defaults,noatime,auto,_netdev 0 0path to LUKS container (file system) is generally /dev/mapper/$LUKS_NAME, where $LUKS_NAME is defined in /etc/crypttab (like taget name)
Systemd Unit
Edit the configuration file located at /etc/systemd/system/systemd-cryptsetup@rbd_luks_pool.service.d/10-deps.conf by adding the following lines.
[Unit]
After=rbdmap.service
Requires=rbdmap.service
Before=mnt-rbd_luks_pool.mountIn one case, systemd units were used on Debian 10, but for some reason ceph-rbdmap.service was used instead of rbdmap.service (this must be adjusted in the lines After= and Requires=)
Manual Connection
If the systemd unit dependencies are correctly configured, it will performs the RBD mapping, unlock LUKS and mount all fs dependent on the rbdmap, as specified in the .mount unit needs (⇒ this will mount both images as described in the configuration).
systemctl start mnt-rbd_luks_pool.mountManual Disconnection
This command should execute correctly if the dependencies are set up properly, umount, close LUKS and unmap RBD.
systemctl stop rbdmap.service
(alternatively `systemctl stop ceph-rbdmap.service`)Image Resize
When resizing an encrypted image, you need to follow the correct order, with the key step being the command cryptsetup --verbose resize image_name.
rbd resize rbd_pool_name/image_name --size 200T
cryptsetup --verbose resize image_name
mount /storage/rbd/image_name
xfs_growfs /dev/mapper/image_nameSnapshots of RBD image
If you want to be able to operate with snapshots yourself, you need to tell us this request.
A snapshot is a read-only logical copy of an image at a particular point in time: a checkpoint. One of the advanced features of Ceph block devices is that you can create snapshots of images to retain point-in-time state history. Ceph also supports snapshot layering, which allows you to clone images (e.g., a VM image) quickly and easily. Ceph block device snapshots are managed using the rbd command and multiple higher level interfaces, including QEMU, libvirt, OpenStack and CloudStack.
Because RBD does not know about any filesystem within an image (volume), snapshots are only crash-consistent unless they are coordinated within the mounting (attaching) operating system. It can be achieved either by unmounting of filesystem and unmapping the RBD image or by usage of fsfreeze command. You can choose any of those two approaches above depending on your use case and system environment. Below are described two basic scenarios.
A In case the RBD image is NOT shared across more machines (see the case B), but there is even minimal risk of mapping your RBD and mounting your filesystem on multiple machines we recommend you to use --exclusive option. In this case, you have to create RBD snapshot on the unmapped RBD image always. You should also make sure that your image is not being mapped on any other device. You can use the command # rbd –id client_name status rbd_pool_name/rbd_image_name. In case that image is not mapped on any machine you should get the following output Watchers: none.
B In case you don’t use the option --exclusive it is sufficient to use fsfreeze command. After the snapshot is done you can enable I/O via fsfreeze with the option -unfreeze. More detail can be found on the man page of fsfreeze(8).
Snapshot basics
The following procedures demonstrate how to create, list, and remove snapshots using the rbd command.
Data increments resulting from the use of snapshots are included in the agreed quota.
Create snapshot
To create a snapshot with rbd, specify the snap create option, the pool name and the image name.
rbd snap create {pool-name}/{image-name}@{snap-name}For example:
rbd snap create rbd/foo@snapnameList snapshots
To list snapshots of an image, specify the pool name and the image name.
rbd snap ls {pool-name}/{image-name}For example:
rbd snap ls rbd/fooRollback snapshot
To rollback to a snapshot with rbd, specify the snap rollback option, the pool name, the image name and the snap name.
rbd snap rollback {pool-name}/{image-name}@{snap-name}For example:
rbd snap rollback rbd/foo@snapnameRolling back an image to a snapshot means overwriting the current version of the image with data from a snapshot. The time it takes to execute a rollback increases with the size of the image. It is faster to clone from a snapshot than to rollback an image to a snapshot, and is the preferred method of returning to a pre-existing state. For more information see documentation.
Snapshot protection
For safe snapshots handling we strongly recommend assigning Protected to each snapshot you create. Protected attribute ensures that you can’t accidentally delete the existing snapshot.
rbd snap protect {pool-name}/{image-name}@{snapshot-name}Example:
rbd snap protect rbd/foo@snapnameUnprotect the snapshots
rbd snap unprotect {pool-name}/{image-name}@{snapshot-name}Example:
rbd snap unprotect rbd/foo@snapnameDelete snapshot
To delete a snapshot with rbd, specify the snap rm subcommand, the pool name, the image name and the snap name.
rbd snap rm {pool-name}/{image-name}@{snap-name}For example:
rbd snap rm rbd/foo@snapnameCeph deletes data asynchronously, so deleting a snapshot doesn’t immediately free up the capacity/quota.
Mapping and mounting the snapshot
Snapshot is possible to map and mount in read-only mode:
rbd map {pool-name}/{image-name}@{snap-name}
mount /dev/rbd/{pool-name}/{image-name}@{snap-name} /mnt/{mountpoint} -o roExample:
rbd map rbd/foo@snapname
mount /dev/rbd/rbd-pool/foo@snapname /mnt/snap -o roBe aware: some filesystems require the use of additional options for the mount command — e.g. XFS:
mount /dev/rbd/rbd-pool/foo@snapname /mnt/snap -o ro,norecoveryLast updated on
