Linux Logical Volume Manager Overview

Do your Linux servers use LVM?

If not, you should strongly consider it.  Unless, you are using ZFS, BTRFS, or other “controversial” filesystems.  ZFS and BTRFS are outside of scope for this discussion but are definitely worth reviewing if you haven’t heard of them and are running Linux in your environment.

Logical Volume Manager for Linux is a proven storage technology created in 1998.  It offers layers of abstraction between your storage devices in your Linux system and the filesystems that live on them.  Why would you want to add an extra layer between your servers and their storage you might ask?

Here are some reasons:

• Flexibility
  • You can add more physical storage devices if needed, and present them as a single filesystem.
  • Online maintenance – Need to grow or shrink your filesystems, online, and in real-time?  This is possible with LVM.
  • It is possible to live migrate your data to new storage.
  • Thin provisioning can be done, which can allow you to over-commit your storage if you really want to.
• Device naming – you can name your devices something that makes sense instead of whatever name Linux gives the device.
  • Meaningful device names like Data, App, or DB are easier to understand than SDA, SDB, SDC
  • This also has the benefit of reducing mistakes when working with block devices directly.
• Performance – it is possible to stripe your disks and improve performance.
• Redundancy – it is also possible to add fault tolerance to ensure data availability.
• Snapshots
  • This is one of my favorite reasons for using LVM.
  • You can take point-in-time snapshots of your system
  • Those snapshots can then be copied off somewhere else.
  • It is also possible to mount the snapshots and manipulate the data more granularly.
  • Want to do something risky on your system, and if it doesn’t work out, have a quick rollback path?  LVM is perfect for this.

So how does it work?

According to Red Hat :
“Logical Volume Management (LVM) presents a simple logical view of underlying physical storage space, such as hard drives or LUNs. Partitions on physical storage are represented as physical volumes that can be grouped together into volume groups. Each volume group can be divided into multiple logical volumes, each of which is analogous to a standard disk partition. Therefore, LVM logical volumes function as partitions that can span multiple physical disks.”

I think LVM is much easier to understand with a diagram.  The above image illustrates some of the concepts involved with LVM.  Physical storage devices recognized by the system can be presented as PVs (Physical Volumes).  These PVs can either be the entire raw disk, or partitions, as illustrated above.  A VG (Volume Group) is composed of one or more PVs.  This is a storage pool, and it is possible to expand it by adding more PVs.  It is even possible to mix and match storage technologies within a VG.  The VG can then allocate LVs (Logical Volumes) from the pool of storage, which is seen as raw devices.  These devices would then get formatted with the file system of your choice.  They can grow or shrink as needed, so long as space is available in either direction for the operation.

You really should be using LVM on your Linux servers.

Without LVM, many of these operations discussed above are typically offline, risky, and painful.  These all amount to downtime, which we in IT like to avoid.  While some may argue that the additional abstractions add unnecessary complexity, I would argue that LVM really isn’t that complicated once you get to know it.  The value of using LVM greatly outweighs the complexity in my opinion.

The value proposition is even greater when using LVM on physical Linux nodes using local storage.  SAN storage and virtual environments in hypervisors typically have snapshot capabilities built-in, but even those do not offer all of the benefits of LVM.  It also offers another layer of protection in those instances.  Alternatively, the aforementioned ZFS and BTRFS are possible alternatives, and arguably better choices depending on who you ask.  However, due to the licensing (ZFS) and potential stability (BTRFS) issues, careful consideration is needed with those technologies.  Perhaps those considerations are topics for a future blog…

Want to learn more?  Please reach out, we’re here to help.

Categories