Organizing partitions on a system disk in a selector cloud
abstract : This post describes the organization of the system disk on machines in the cloud and explains why.
Preface : Everything written here concerns system disks created during installation of virtual machines. Users have every right to do what they want with these discs, and, moreover, decide on their own how to organize a place on additional disks.
We must provide system disks in a form that gives users enough freedom to do “what you want,” and at the same time provide sufficient simplicity and convenience for users who need to “just work”. Although the problem is a little more complicated, since this is not about a convenient TV remote, but about a tool in work, so it’s more correct to talk about the convenience of typical scenarios and the ability to implement your own.
')
Here are the problems that arise in connection with this:
The most primitive solution is the entire disk file system (/ dev / xvda mounted as '/'). It is very easy to change in size, after changing the size of the block device, simply run the resize command for the file system. It is also easy to connect to other virtual machines. However, the lack of a partition table leads to the fact that additional partitions cannot be created - a common collective farm: root, home and / var / www (for someone it is / srv / www, for someone / home / websitename, etc. ) appear on the same partition with / var / log and other service files. It is easy, simple, but it does not pull at all on the role of an advanced instrument. And most importantly, new sections can be made only by connecting additional disks. Moreover, even the swap partition cannot be made, you have to get rid of fallocate or dd to create the page file.
The second option is a good old partition table. / dev / xvda1, / dev / xvda5, / dev / xvda6, etc. Pros: simple, understandable, easy to connect to other machines, but it is very difficult to change the size, for example, root. You need to delete the swap partition, resize the partition in the partition table, resize the file system, do something with the paging file. If the disk has partitions with data, you need to run creepy and dangerous procedures for moving the partition table (and taking into account paid disk operations, this is not an option at all).
And finally, the third option - LVM. What is good: resizing the file system is possible and very simple. Easy to add / delete sections. At the same time, we have some solvable problems with connecting disks to other machines (like what problems there are - see below). However, there is a little problem. With lvm we can not boot. Totally.
So I had to make it less convenient, but the fourth working option.
A partition table with two primary (primary) partitions is created on the system disk: / dev / xvda1 - / boot and / dev / xvda2 - physical volume for LVM. The kernel load comes from / dev / xvda1, which is small and (in a good way) should not change in size, the file system and the paging file to LVM inside the second partition.
Pros? You can solve all tasks: resizing a partition, connecting to other machines, loading, creating an unlimited number of partitions.
Minus: resize is no longer "easy and simple" - a little bit will have to strain. But still possible with reasonable efforts.
Since there are no unsolved problems in this version, we stopped at it. I, of course, would prefer to have a “pure LVM”, but its parsing from pygrub is too complicated, especially considering the presence of a superior LVM (we use LVM over iSCSI to store clients' disks).
Let's start with the most common - resizing the system partition.
Complicated? Yes. Flexible and functional? Yes! Why? Because the use of LVM opens up many "workarounds". For example, you can increase the size of a partition that is not the last in the list. Or, for example, you can easily create any number of logical volumes you need.
A little about ptmax. It so happened that we (I) had to write this utility from scratch. The code itself is there with Gulkin’s nose, most of which are “whether we do everything right” checks. The essence of the utility - if in the partition table the partition has free space behind it, it increases the partition to the maximum possible size. Typical script to increase the size of the virtual machine disk.
Previously, this had to be done using the “delete / re-create” partition in fdisk, which, to put it mildly, was not very safe. Utility under the GPL, traditionally on the github: github.com/amarao/ptmax .
A little bit about dots. Instead of dots,use tab to use the name VG, which is used in the machine. The VG name contains the hostname at the time of installation (% hostname% _system). Why do we use it? Because if we used the same name, there would be a collision when connecting the disk to another machine (and the collision could be solved by renaming VG, but only in one direction - you cannot set the same name for the second VG in the system) . So each VG of each car has its “own” name. Predicting questions: use the same server name for two different virtual machines — moveton.
The second typical scenario is the creation of another section. By and large, it differs little from the first procedure:
The following scenario is a bit more complicated - connecting the disk to a “foreign” virtual machine.
After connecting the drive, you need to activate VG:
After the end of the work, if the disk needs to be disconnected, it is necessary to do “deactivation”:
After that, the disc can be turned off "on the go."
PS I repeat once again, we are talking only about the system disk (/ dev / xvda), which is formed after installing the virtual machine. You can connect additional disks and change their size in any way convenient for you.
Preface : Everything written here concerns system disks created during installation of virtual machines. Users have every right to do what they want with these discs, and, moreover, decide on their own how to organize a place on additional disks.
Motivation
We must provide system disks in a form that gives users enough freedom to do “what you want,” and at the same time provide sufficient simplicity and convenience for users who need to “just work”. Although the problem is a little more complicated, since this is not about a convenient TV remote, but about a tool in work, so it’s more correct to talk about the convenience of typical scenarios and the ability to implement your own.
')
Here are the problems that arise in connection with this:
- Ability to change the size of the disk and the root file system
- Ability to create additional sections
- The ability to connect drives from one machine to another
- From this disk it is also necessary to boot.
The most primitive solution is the entire disk file system (/ dev / xvda mounted as '/'). It is very easy to change in size, after changing the size of the block device, simply run the resize command for the file system. It is also easy to connect to other virtual machines. However, the lack of a partition table leads to the fact that additional partitions cannot be created - a common collective farm: root, home and / var / www (for someone it is / srv / www, for someone / home / websitename, etc. ) appear on the same partition with / var / log and other service files. It is easy, simple, but it does not pull at all on the role of an advanced instrument. And most importantly, new sections can be made only by connecting additional disks. Moreover, even the swap partition cannot be made, you have to get rid of fallocate or dd to create the page file.
The second option is a good old partition table. / dev / xvda1, / dev / xvda5, / dev / xvda6, etc. Pros: simple, understandable, easy to connect to other machines, but it is very difficult to change the size, for example, root. You need to delete the swap partition, resize the partition in the partition table, resize the file system, do something with the paging file. If the disk has partitions with data, you need to run creepy and dangerous procedures for moving the partition table (and taking into account paid disk operations, this is not an option at all).
And finally, the third option - LVM. What is good: resizing the file system is possible and very simple. Easy to add / delete sections. At the same time, we have some solvable problems with connecting disks to other machines (like what problems there are - see below). However, there is a little problem. With lvm we can not boot. Totally.
So I had to make it less convenient, but the fourth working option.
Our solution
A partition table with two primary (primary) partitions is created on the system disk: / dev / xvda1 - / boot and / dev / xvda2 - physical volume for LVM. The kernel load comes from / dev / xvda1, which is small and (in a good way) should not change in size, the file system and the paging file to LVM inside the second partition.
Pros? You can solve all tasks: resizing a partition, connecting to other machines, loading, creating an unlimited number of partitions.
Minus: resize is no longer "easy and simple" - a little bit will have to strain. But still possible with reasonable efforts.
Since there are no unsolved problems in this version, we stopped at it. I, of course, would prefer to have a “pure LVM”, but its parsing from pygrub is too complicated, especially considering the presence of a superior LVM (we use LVM over iSCSI to store clients' disks).
Typical operations
Let's start with the most common - resizing the system partition.
- Increase the size of the block device (control panel)
- Run ptmax / dev / xvda2
- Reboot (thanks to Linux, who refuses to reread the locked disk with the root partition)
- Run the pvresize / dev / xvda2 command
- Look at free PE in VG: vgdisplay
- Increase the size of the logical volume: lvresize /dev/../root -l + (number of free extents)
- Resize filesystem: resize2fs /dev/../root
Complicated? Yes. Flexible and functional? Yes! Why? Because the use of LVM opens up many "workarounds". For example, you can increase the size of a partition that is not the last in the list. Or, for example, you can easily create any number of logical volumes you need.
A little about ptmax. It so happened that we (I) had to write this utility from scratch. The code itself is there with Gulkin’s nose, most of which are “whether we do everything right” checks. The essence of the utility - if in the partition table the partition has free space behind it, it increases the partition to the maximum possible size. Typical script to increase the size of the virtual machine disk.
Previously, this had to be done using the “delete / re-create” partition in fdisk, which, to put it mildly, was not very safe. Utility under the GPL, traditionally on the github: github.com/amarao/ptmax .
A little bit about dots. Instead of dots,
The second typical scenario is the creation of another section. By and large, it differs little from the first procedure:
- Increase the size of the block device (control panel)
- Run ptmax / dev / xvda2
- Reboot (thanks to Linux, who refuses to reread the locked disk with the root partition)
- Run the pvresize / dev / xvda2 command
- Look at free PE in VG: vgdisplay
- Create a section: lvcreate / dev / VGNAME -n LVNAME -L XXXMb
- Create a file system on it: mkfs.ext4 / dev / VGNAME / LVNAME
- mount the system and register it in fstab
The following scenario is a bit more complicated - connecting the disk to a “foreign” virtual machine.
After connecting the drive, you need to activate VG:
- pvscan / dev / xvdb (or other device name)
- vgscan
- lvscan
- lvdisplay
- lvchange -ay / dev / VGNAME / LVNAME (visible in the output of the previous paragraph)
- mount / umount
After the end of the work, if the disk needs to be disconnected, it is necessary to do “deactivation”:
- lvchange -an / dev / VGNAME / LVNAME
- vgchange -an / dev / VGNAME
- pvchange -an / dev / xvdb
After that, the disc can be turned off "on the go."
PS I repeat once again, we are talking only about the system disk (/ dev / xvda), which is formed after installing the virtual machine. You can connect additional disks and change their size in any way convenient for you.
Source: https://habr.com/ru/post/139152/
All Articles