Forget what you might have heard about host-based volume managers. Here are seven reasons why they deserve some...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Host-based volume managers (also known as logical volume managers or LVMs) are the most underrated or underutilized components in storage ecosystems, even though they've been around almost as long as open systems. Perhaps because they're host based or often managed by sys admins, many storage administrators don't consider LVMs part of their toolset. I'll set the record straight regarding LVMs and, hopefully, encourage storage administrators to use them to improve the performance of their storage environment.
MYTH 1: LVMs aren't required for good performance or balance.
Technically, volume managers aren't necessary for hosts such as Fibre Channel, iSCSI, parallel SCSI, JBOD or hardware RAID to access storage. To some extent, storage (hardware) vendors have made matters worse by creating a general dislike for the use of any host-based utilities that duplicate functions in their arrays, primarily RAID.
However, as the source of all IO, a host has a lot of control over how IO is distributed along the path and its final destination (the array itself). LVMs let you control and distribute this IO without putting the entire onus on the array, which may not be sufficient.
Most LVMs work by introducing a logical layer between the IO access methods (such as file systems) and the physical access layer (such as device drivers). This logical layer is capable of performing multiple functions such as software RAID, which, when used with device-access mechanisms, allows IO to be spread uniformly across "egress" paths such as host bus adapters (HBAs). This way, when the host gets busy, the array doesn't see all of the access coming in--or headed to--a single location, keeping its own IO subsystem balanced.
MYTH 2: LVM is a system administrator's problem.
Many storage administrators don't get involved in how storage is accessed on the host. That's a mistake. Let's say a host requires 1TB of storage and the application folks haven't made it clear as to how they're planning to access this storage. Storage administrators who distance themselves from host-provisioning activities open the door to interpretation. A systems administrator might create four 250GB file systems, two 500GB file systems or a single 1TB file system.
Each scenario will create a very different IO profile on the array, and each one has the potential to create IO contentions or bottlenecks. No one looking only at the host will be able to tell which scenario is the most efficient from a storage perspective. The only person who can intelligently estimate this is the storage administrator. With the aid of tools such as LVMs, storage admins can find out ahead of time how this storage will be accessed and then provide a recipe for how they expect the host components to be configured. Moreover, it's no longer necessary to log in to each server to look at how LVM components are configured or to make changes. They can all be managed centrally. Nearly every LVM vendor provides a GUI for performing routine provisioning and management functions, either in a direct manner or through a hook into a centralized management toolset (such as Symantec's Veritas CommandCentral Storage).
MYTH 3: If you have multipathing software, an LVM isn't necessary.
Multipathing software is a mixed bag. Almost all storage hardware vendors provide their own flavor, and OS vendors do the same. Vendors such as Symantec bundle multipathing software with their LVM product (Veritas Volume Manager). However, no multipathing software should eliminate the need for LVM on the host. This is because multipathing software controls only how IO leaves the host, through HBA ports for example, and not how the host accesses the storage. A more prudent policy is to tightly couple the multipathing policy with that of the LVM (and file-system) policies. You may encounter interoperability challenges, but the additional support should outweigh any obstacles.
MYTH 4: LVM is for Unix servers only.
The culprit here is Windows. I know there are a lot of folks (including those at Microsoft) who are trying to change this view, but there are plenty of people who still believe they should use LVMs for Unix variants and leave everything for Windows and Windows-like platforms to the array.
Unix vendors have been bundling LVMs with their operating systems for a very long time. But many Windows users aren't aware that an LVM is bundled (yes, bundled) by Microsoft in their Windows server builds. This LVM (which is an OEM version of Veritas Volume Manager) may not provide you with the bells and whistles of a fully licensed version, but it offers plenty of benefits. I also see a lot of Linux environments that don't make use of the LVM bundled with distributions such as Red Hat and SUSE. They should.
MYTH 5: Only commercial LVMs are effective.
This myth is probably the result of a marketing spin that Veritas (now Symantec) tried with its Volume Manager product. For the record, I'm a big fan of Veritas Volume Manager. But it's also a licensed commercial product. (The good news is that vendors like Microsoft and now Hewlett-Packard have started offering it with their OS distributions.)
These days, almost every operating system comes with an LVM package. IBM's AIX and HP's HP-UX have LVMs (and they do call it LVM). Sun Microsystems ships Solaris with Solaris Volume Manager (SVM) and Sun's ZFS has its own variant. With a few exceptions, nearly all Unix environments prefer to use LVM for root disk mirroring as opposed to hardware RAID. LVM in Unix environments is almost a given, but it doesn't have to stop there.
Symantec's Veritas Volume Manager is a good option if you have a very diverse operating system environment, need single software access across all of your servers and can afford it. It's a powerful package that's bundled with Dynamic MultiPathing (DMP), one of the best multivendor multipathing packages out there.
MYTH 6: LVMs can cause a performance overhead on the host.
Some people may still believe an LVM introduces latency on the host and takes away precious CPU and memory resources that could have been allocated for app performance. Not true. CPU and memory units have become inexpensive and servers more powerful. And improvements in technology have allowed vendors to make LVMs more efficient.
It's important to mention that parity-based RAID levels, such as RAID-5, are still off limits for LVMs. Many vendors have tried to make them efficient, but my preference is to leave those functions to the hardware arrays.
MYTH 7: LVMs can't provide data mobility and protection.
Almost all LVMs these days contain some form of data mobility functionality in addition to core functions such as RAID protection. These features vary depending on the vendor and they're still proprietary. However, most vendors support data migration functions, network-based remote replication for off-host processing or disaster recovery, and snapshots and point-in-time copies for off-host processing and backups.
That said, there may be certain efficiencies in performing these functions within the storage array, but it will come at a cost. Many operating system vendors that provide LVM packages bundle such features or offer them at a fraction of the cost. LVM-based data mobility should therefore be evaluated to see if it's a cheaper and more viable option for your requirements. Some LVMs are also now capable of providing clustering support for apps such as Oracle RAC 10g.
The performance of a storage subsystem hinges on how its "customers" (the hosts) access it. An LVM can play the role of traffic cop, and its value should never be underestimated or overlooked.