When managing Azure virtual machines that need better disk performance, the best solution is to find a VM that allows more and better disks and add those disks in parallel. Sometimes a single disk is not enough to meet application disk performance requirements. In this article, we are going to help two different audiences, those who are studying for Red Hat of Linux Foundation certification and need some hands-on experience on the logical volume manager (LVM) feature, and the cloud administrators group who need to manage their Linux workloads in Microsoft Azure. The operating system (in this article we are using Red Hat) has to use the new disks efficiently, and we are going to configure LVM in our Red Hat Linux.
The LVM combines multiple physical disks (physical volumes in LVM world) in a volume group. The volume group can present to the operating system logical volumes and are in that component that we define the size.
Using this approach has several benefits: The system is not limited to a capacity of a single disk and the application/user that interacts with the system only sees a logical volume. In the case of Azure, we can combine several disks, thus improving IOPS and throughput.
In the diagram below, we are highlighting the components that we will be working on in this article. On the right side, the Azure VM with its disks and their associated mapping in the Linux (/dev/sdX) and on the left a bird’s eye view of the operating system (LVM and its tiers and the folder structure in the Red Hat Linux file system).
We are going to start creating three data disks and attach them to the Red Hat Linux Azure VM. We are going to select E4 disks. They have 32GB size and a max IOPS of 120 and the throughput of 25.
The result will be similar to the image below. Doing basic math, we are adding three disks, so we are expecting three times those values, meaning 360 max IOPS and 75 max throughput.
The first step is to validate that the operating system sees our new disks. We can use ll /dev/sd*, the results are new disks sdc, sdd, and sde. To confirm that we are looking at the right disks, we can always use sudo fdisk -l /dev/sdc /dev/sdd /dev/sde and the output will be more detailed information about the disks (32GB disks).
The first step is to add the physical disks, and we can do that by running the first command listed below. To check if the disks were added, we can use pvdisplay, and both commands are depicted in the image below.
sudo pvcreate /dev/sdc /dev/sdd /dev/sde Pvdisplay
The output will include useful information, including size, association with a volume group (in our case empty for now), and their UUID.
The second step is to create a volume group. The process is simple. We need to pass the physical disks that were created before the vgcreate command, and on the same command, we are going to define the name of the volume group. Both commands’ syntax and their outputs are described in the commands and picture below.
sudo vgcreate vg-db-data /dev/sdc /dev/sdd /dev/sde sudo vgdisplay vg-db-data
The new volume group is called vg-db-data, and it is 96GB in size.
The next step is to create the logical volume. It is paramount to use the --stripes <numberOfDisks> to take advantage of Azure Disks. After creating the logical volume, we will check its settings.
sudo lvcreate --extents 100%FREE --stripes 3 --name db-data vg-db-data sudo lvdisplay /dev/vg-db-data/db-data
An LVM has a special structure in the /dev folder. It has its folder with the name of the volume group, and inside of that volume group, we will have a reference to the logical volume.
Since we have a logical volume, we can assign a file system to it, and we can do that by executing sudo mkfs.ext4 /dev/vg-db-data/db-data. The process may take a few seconds, wait for the completion.
We can test the mount of the new logical volume that we have just formatted as ext4. First, we are going to retrieve the logical volume path by running sudo lvdisplay /dev/vg-db/data/db-data.
Next, we need to create a folder structure to mount the new volume. We will accomplish that by running sudo mkdir /mnt/db-data, and then we will mount the logical volume into the new folder that we have created by executing sudo mount /dev/vg-db-data/db-data /mnt/db-data. The final step is to run df -h, and we should see the 96GB partition mounted using the variables that we have gathered in the previous actions. A summary of the entire process is depicted in the image below.
Although the process is complete, if we restart this server, the logical volume will not be mounted automatically. We are going to configure it to be persistent. For now, we are going to remove the existing mount using sudo umount /dev/db-data.
Configuring persistent volume
The configuration file that controls the process to mount volumes in Linux automatically is the /etc/fstab. When using LVM, we need to specify the logical volume, and we have two options, from the mapper folder or directly to the logical volume.
The first step is to list our logical volume using sudo lvdisplay /dev/<volumeGroup>/<LogicalVolume>. We can check the /dev/mapper folder contents to see the links. The link name is always the volumeGroup-logicalVolume (mapper does not like dashes. If it finds it will add one extra, that is the reason we have db—data).
Our next step is to edit the /etc/fstab and we can use either the /dev/mapper or /dev/<volumeGroup>/<logicalVolume> and define the mount point and additional configuration. If you are using Azure Premium disks, make sure to add barrier=0 your settings.
The final step is to mount all volumes defined in the /etc/fstab, and we can do that by executing sudo mount -a, and to verify if the mount was successful, we can run df -h.