However, in the general case, it might make sense to put everything on a single big EBS volume, and use LVM (or, I suppose, plain partitions).
You can (now) increase the size of EBS volumes (virtual disks) on-the-fly, and resize partitions, etc. With AWS you can follow my advice above and you'll often be just fine.
I don't know much about Azure, GCP, or any of the smaller players, so I can't help there. Meanwhile, if you are using a cloud provider, it's more subtle. Using LVM would allow you to hot-add a virtual disk (presuming your hypervisor/OS combination allows this), and expand the filesystem without a reboot. And don't forget to properly align your partitions - starting the first partition at 1MB is a good rule of thumb.Īll that said - Doing this all at the hypervisor level means that you probably have to reboot the VM to resize partitions. It does mean one more step when resizing the filesystem, though. I'd recommend just putting a single partition on the disk and be done with it. This is a fine idea, but.most tools (and other admins who come after you) will expect to see partitions on every disk. When creating the filesystem, just do something like mke2fs -j /dev/vdc instead of specifying a partition. For example, you can create a virtual disk for /home it is /dev/vdc inside your vm. You don't even necessarily need to put partitions on your virtual disks this way. One thing you might think of as you go down this road.
If you want to be able to arbitrarily resize file systems (a fine idea), just create a separate virtual disk for each filesystem. Remember, the hypervisor is already effectively performing these tasks. It doesn't buy you much flexibility that you couldn't get at the hypervisor level. If you are on an environment that you control (vmware or kvm or whatever), and can make your own decisions about disk performance QoS, then I'd recommend not using LVM inside your VMs.
0 kommentar(er)
