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 ...

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.

< PREV PAGE   |   1  |   2  |   3  |   4  |   NEXT PAGE  >