Running a customer’s technical infrastructure often necessitates making changes in response to the shifting requirements of the industry. Thankfully, with the introduction of cloud computing, adapting the infrastructure has never been easier. These days, we can quickly add or remove resources as conditions dictate.
Historically, businesses’ storage capacity needs have fluctuated, and responding to these ever-changing needs has required regular attention. In the past, altering storage capacity typically meant expanding it—a tedious and time-consuming process. Recently, however, cloud computing has made increasing capacity much easier.
In this blog, we will be looking at the processes involved with how to resize EBS volumes in AWS. Once you increase the volume size on the cloud provider level, the commands to increase the size on the OS level will be the same irrespective of the cloud provider.
Suppose a customer is running an environment on an EC2 instance—perhaps a small application that doesn’t require many resources. Since this application uses little storage, a small 15 GB general purpose AWS EBS volume has been attached. As the business needs grow, the customer would like to add more AWS resources, making it necessary to grow your EBS volume to support more data. Needless to say, you would prefer to do this without any downtime. I have divided this into three parts and further subdivided them. The first part will be where we are going to see how we will extend the underlying volume. Following how we can resize the volume depending on the use case like whether the disk is partitioned, not partitioned, or using LVM. In the end, we will be expanding the file system.
Extending underlying volume
Below are steps performed on AWS EBS, you can check and do it as per your cloud service provider.
First, you need to log in to your AWS account and go to the volume and choose the volume you want to resize. After selecting the volume click on “Modify volume” under “Action”.
You are then given the option to change both the disk size and the volume type. You can increase the size now.
Once you increase the volume, wait till it reflects on instance level and on OS too. In this blog, we’ll extend the volume to 20 GB and retain the volume type. After the volume has been extended, the EC2 instance and the system both need to be adjusted to adapt to the new size. Note that you can do this adjustment either as a root or as a user with Sudo privileges. Below I will do it as a root user.
Resizing volume
- Below are the steps you have to perform when you have an LVM.
- The first step in this process is checking the volume, partition, and LVM size.
Before extending the underlying volume:
1 2 3 4 5 6 7 | # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 25G 0 disk └─xvda1 202:1 0 25G 0 part / xvdf 202:80 0 15G 0 disk └─xvdf1 202:81 0 15G 0 part └─mongovg_new-mongolv_new 253:0 0 15G 0 lvm /mongodb |
After extending the underlying volume:
1 2 3 4 5 6 7 | # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 25G 0 disk └─xvda1 202:1 0 25G 0 part / xvdf 202:80 0 20G 0 disk └─xvdf1 202:81 0 15G 0 part └─mongovg_new-mongolv_new 253:0 0 15G 0 lvm /mongodb |
The above shows that the volume has been extended when the disk has LVM. However, the disk having the primary partition is still at the volume’s original size.
2. To expand the partition, use the below command. After you do so, you will see that the partition has grown to match the volume size.
1 2 | # growpart /dev/xvdf 1 CHANGED: partition=1 start=2048 old: size=31455199 end=31457247 new: size=41940959 end=41943007 |
1 2 3 4 5 6 7 | # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 25G 0 disk └─xvda1 202:1 0 25G 0 part / xvdf 202:80 0 20G 0 disk └─xvdf1 202:81 0 20G 0 part └─mongovg_new-mongolv_new 253:0 0 15G 0 lvm /mongodb |
Note that there is a space between “/dev/xvdf” and “1.” “1” refers to the partition number.
Also, if you do not have growpart installed, you can do it using the below command:
1 | # yum install -y cloud-utils-growpart |
Above you can see that the partition has been expanded.
3. Now we are going to expand the LVM. In order to do that, first we need to resize the physical volume. Resize physical volume:
1 2 3 | # pvresize /dev/xvdf1 Physical volume "/dev/sdf1" changed 1 physical volume(s) resized or updated / 0 physical volume(s) not resized |
Extending size of LV:
Below we have extended the LV to 100% of free space-
1 2 3 | # lvextend -l +100%FREE /dev/mongovg_new/mongolv_new Size of logical volume mongovg_new/mongolv_new changed from <15.00 GiB (3839 extents) to <20.00 GiB (5119 extents). Logical volume mongovg_new/mongolv_new successfully resized |
1 2 3 4 5 6 7 | # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 25G 0 disk └─xvda1 202:1 0 25G 0 part / xvdf 202:80 0 20G 0 disk └─xvdf1 202:81 0 20G 0 part └─mongovg_new-mongolv_new 253:0 0 20G 0 lvm /mongodb |
If you want to extend the LV to a particular size then you can use the below command (for example I have increased it by 3G):
1 | # lvextend -l +3G /dev/mongovg_new/mongolv_new |
1 2 3 4 5 6 7 | # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 25G 0 disk └─xvda1 202:1 0 25G 0 part / xvdf 202:80 0 20G 0 disk └─xvdf1 202:81 0 20G 0 part └─mongovg_new-mongolv_new 253:0 0 18G 0 lvm /mongodb |
- Below are the steps when you don’t have a partition:
- First, you need to check the volume size.
Before extending the volume:
1 2 3 4 5 | # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 25G 0 disk └─xvda1 202:1 0 25G 0 part / xvdf 202:80 0 15G 0 disk /mongodb |
After extending the volume:
1 2 3 4 5 | # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 25G 0 disk └─xvda1 202:1 0 25G 0 part / xvdf 202:80 0 20G 0 disk /mongodb |
The above shows that the volume has been extended when the disk does not have any partition.
- Below are the steps when you have a partition.
- The first step in this process is checking the volume and partition size.
Before extending the underlying volume:
1 2 3 4 5 6 | # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 25G 0 disk └─xvda1 202:1 0 25G 0 part / xvdf 202:80 0 15G 0 disk └─xvdf1 202:81 0 15G 0 part /mongodb |
After extending the underlying volume:
1 2 3 4 5 6 | # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 25G 0 disk └─xvda1 202:1 0 25G 0 part / xvdf 202:80 0 20G 0 disk └─xvdf1 202:81 0 15G 0 part /mongodb |
The above shows that the volume has been extended when the disk has a partition. However, the disk having the primary partition is still at the volume’s original size.
2. To expand the partition, use the below command. After you do so, you will see that the partition has grown to match the volume size.
1 2 | # growpart /dev/xvdf 1 CHANGED: partition=1 start=2048 old: size=31455199 end=31457247 new: size=41940959 end=41943007 |
1 2 3 4 5 6 | # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 25G 0 disk └─xvda1 202:1 0 25G 0 part / xvdf 202:80 0 20G 0 disk └─xvdf1 202:81 0 20G 0 part /mongodb |
Note that there is a space between “/dev/xvdf” and “1.” “1” refers to the partition number.
Also, if you do not have growpart installed, you can do it using the below command:
1 | # yum install -y cloud-utils-growpart |
Above you can see that the partition has been expanded.
Expanding file system
Now the file system size needs to be checked. Below you will notice that it is still only 15GB, even though the volume/partition/LVM has been resized above.
1 2 3 4 5 6 7 8 9 | # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 484M 0 484M 0% /dev tmpfs 492M 0 492M 0% /dev/shm tmpfs 492M 428K 491M 1% /run tmpfs 492M 0 492M 0% /sys/fs/cgroup /dev/xvda1 20G 4.1G 16G 21% / tmpfs 99M 0 99M 0% /run/user/1000 /dev/mapper/mongovg_new-mongolv_new 15G 48M 15G 1% /mongodb |
In our case, since the file system is XFS, we have to rely on the “xfs_growfs” tool, which should already be in the system. If not, you can install it yourself as part of the “xfsprogs” package.
You can run the below command to expand the XFS Filesystem:
1 2 3 4 5 6 7 8 9 10 11 | # sudo xfs_growfs /mongodb meta-data=/dev/xvdf isize=512 agcount=4, agsize=983040 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1 spinodes=0 data = bsize=4096 blocks=3932160, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 data blocks changed from 3932160 to 5242880 |
1 2 3 4 5 6 7 8 9 | # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 484M 0 484M 0% /dev tmpfs 492M 0 492M 0% /dev/shm tmpfs 492M 428K 491M 1% /run tmpfs 492M 0 492M 0% /sys/fs/cgroup /dev/xvda1 20G 4.1G 16G 21% / tmpfs 99M 0 99M 0% /run/user/1000 /dev/mapper/mongovg_new-mongolv_new 20G 48M 20G 1% /mongodb |
If you are using an ext4 file system, you could extend it using the below command:
1 | resize2fs /dev/xvda1 |
The volume is now fully resized and ready to be used, and no downtime resulted from this process. You can extend any other partition with the steps shown above, and you just have to ensure you’re using LVM and know the partition you’re extending.
