A further look at business continuance volumes

A further look at business continuance volumes.

A proactive approach to laying out data enables the magic of mirroring for business continuance and replication.

As discussed in the April issue, (see "Integration") implementing business continuance volumes (BCVs) can be a tricky proposition. Data must be mapped from the application to physical storage if mirrors are to be useful for backup, testing or decision support. Storage managers need to plan their disk layouts to facilitate mirroring and sharing.

Storage space is abstracted at many levels within the data path with little visibility from layer-to-layer. Disks are combined into RAID sets. Those sets are then presented to servers as logical unit numbers (LUNs). The LUNs are combined into volume groups, which are carved into volumes. Volumes host filesystems and filesystems contain files, which contain data. Users want data - not LUNs - but arrays can only act on LUNs. While storage vendors are working on automated mapping of content to physical devices, such products are few and immature.

The BCV layout problem stems from this basic fact: Array-based mirroring works at a level far below the application, with no real understanding of the stored data's meaning. Administrators want to protect and share filesystems, but array-based mirroring operates on disks, or LUNs instead. The trick to configuring BCVs is to lay out storage so the mirror images of the disks will contain entire usable filesystems.

A poor configuration can make BCV use impossible. With a single filesystem spread across a number of disks, every one would need to be mirrored, or the copy would be useless. However, when all the disks are mirrored, everything on them would be mirrored - which is unnecessary at best - and problematic at worst. In an extreme case, a customer could use a volume manager to spread parts of a volume across every disk visible to the server, even across multiple arrays. If one of the arrays didn't support mirroring, this would eliminate the possibility of BCV use altogether for this volume. Even if all the arrays do support mirroring, it would be difficult to create a scripted procedure to synchronize or split all the volumes when needed. Storage companies are working diligently on software, such as EMC's Replication Manager, to automate the process of using BCVs, but no solution can make impossible configurations functional.

While BCV use requires that filesystems be consolidated on a few disks, traditional performance tuning wisdom is that they be spread across as many spindles as possible. These contradicting demands are often apparent in design meetings, where storage and database administrators argue the extreme opposite layout choices. Storage administrators should stick to their guns, since the large caches and hardware RAID found in modern arrays obviates the need for extreme performance tuning.

Similarly, ad hoc volume management processes can lead to parts of a volume sprawling across many disks. The ease of adding new disks to a volume group and resizing logical volumes and filesystems can make this a tempting practice. Imagine the jumbled mess after a few years.

Laying out volumes to enable BCVs
"The performance/management trade-off" diagram shows three possible configurations for a simplified Oracle server layout. In this example, with four disks and four filesystems, a volume manager is used to stripe volumes and filesystems across multiple disks.

Option 1 represents the traditional method of spreading volumes across as many disks as possible. In this case, a mirror of the disks holding the database would also contain the control and log files. There is simply no way to mirror the database separately from the rest.

Option 2 is obviously no good from a performance or space perspective. Here, each volume has its own disk, making BCV operations simple. But control files are tiny, and a dedicated LUN hardly makes sense below 1GB.

Option 3 is the right choice. The database has a pair of disks, and everything else shares another pair. BCV copy of the database would be separate from the rest, giving it more space than the control filesystem.

Rather than mirroring at the array level, a volume manager can be leveraged to create BCVs of logical volumes directly. This approach eliminates the challenge of mapping volumes to LUNs, and seems also to simplify layout planning. However, for volume manager-based mirrors to be considered BCVs, they need to be exportable, so they can be shared with other systems. This is trickier than it may seem.

Volume managers such as Veritas' Volume Manager allow mirrors of logical volumes to be created in a disk group, and then split and exported into a separate disk group. This mirror disk group can then be imported on another server, as long as the second server can see all the LUNs the mirror was placed on. The benefit of using a volume manager to make the copy is that it has complete knowledge of the logical volumes, ensuring that the mirror is a complete and correct copy of the original. The disadvantage is that the creation of the mirror sends data flooding over the server bus, potentially impacting performance.

Creating mirrors within a single server is simple - exporting them as BCVs is the challenge. After the copy is made, the LUNs containing the mirror volumes must be released by the source server and turned over to the target. As shown in "Server-based mirroring," this is impossible if the source and mirror reside on the same LUN. Therefore, sufficient extra LUNs must be reserved exclusively for BCV use, just as with array-based BCV solutions.

For servers with complex volume layouts, using a volume manager for mirroring will be easier to configure and maintain than an array-based solution. Servers with just a few drives, or those with strict performance requirements, would benefit from array-based BCV solutions. Furthermore, both array- and server-based BCVs require the same planning and care as with all other aspects of storage management. A complete understanding of the entire storage environment - from application to disk - makes the magic of mirroring possible. 

The performance/management trade off

Plan your disk space layout to accommodate both performance and continuance applications. These three examples of a simplified Oracle database layout show the correct balance.

Server-based mirroring

If you want to export your volume manager-based BCVs, you have to put them on separate LUNs.

So, is a BCV a LUN or a volume?
You will often see the terms disk, volume and LUN used interchangeably to name the storage that is presented from the storage array to the server. While a single disk could be directly presented as a LUN, modern storage systems typically combine multiple disks in a RAID set, and present that set, or part of it, to a server. LUN is probably the best term for a unit of storage, at least from the server perspective, since it specifically refers to any SCSI logical unit of block storage visible to a server.

On the server side, volume, drive and filesystem are quite similar terms: A volume (or drive, in the Windows world) is an addressable unit of space seen by the operating system. If storage is attached using SCSI (or Fibre Channel, which uses SCSI commands), each LUN will appear as an individual volume or drive. A volume manager can combine volumes into volume groups, and then carve space out as logical volumes for the operating system to use. Whether using a volume manager or not, a filesystem is the addressable data structure on a volume that is used for file storage.

Business continuance volume (BCV), snapshot and mirror are also commonly used interchangeably. They all refer to a mirrored copy of a LUN or volume. Some BCV technology works at the storage array level to mirror LUNs, while other types work at the server volume manager level. Snapshots are similar, but specifically refer to delta or incremental block copies of volumes, as opposed to full mirrors.

@ exe

Dig Deeper on SAN technology and arrays