|
|
|
 |
 [1] HP-UX system adminstration – Disk Virtualisation: David L. Totsch |
 |
|
 |
[1] HP-UX system adminstration – Disk Virtualisation: David L. Totsch
by David. L. Totsch
Disk virtualization has been around for quite some time. When we first contemplate the subject, most of us think "big box" (EMC, XP512, etc.). But stop and think for a moment: Isn't LVM nothing more than kernel-based disk virtualization? Now, if you take an HP AutoRAID, add Fibre Channel, upgrade the redundancy scheme, expand capacity using FC60 techniques, and sprinkle it with some software, you end up with an HP SureStore Virtual Array 7400. Of course, it retains all of the characteristics the performance-conscious love to hate, but it fills the space of cost effective, media-efficient, highly available storage. Personal opinions aside, what do we need to make one of these fancy arrays work with HP-UX? As with any other storage, you have to worry about connectivity, configuration, and management.
Connectivity ranges from simple to extreme SAN. The VA7100 and VA7400 both sport two Fibre Channel ports. You can direct connect your HP-UX box for the simple solution, or you can venture into the realm of Storage Area Networks, where you can satisfy just about any complexity addiction. In either case, you need to make sure that the host bus adapters and their drivers can do what you want them to do. One of the attractive points of having a VA on a SAN is that it can support hosts running one of those other operating systems.
Once you have the connectivity in place, you get to configure the array. From HP-UX you have three choices: (1) command-line, (2) a menu interface and (3) a Java GUI (sigh) called Command View Storage Device Management. Table 1 is a list of available commands once Command View SDM is installed and patched. A complete hardware install should leave the array with a small LUN 0 configured. This LUN is suitable for communicating with the array. Please keep in mind that configuration commands are issued in-band—they traverse the same path as your data. If the array does not have a LUN 0, then you will get to play with the virtual front panel to create one. The VFP is nothing more than a completely unsecured serial port back door. The magic incantation to get you going is vfphelp. You can take it from there.
Before we begin creating LUNs from HP-UX, we should verify connectivity. Fire up armdiscover and make sure that your host can communicate with the array. armdiscover will show you several useful pieces of information about the array. You will need one of the following to specify the array to manage to the array manager commands: Serial Number, Alias Name, Worldwide Name, Device File, or Unique Name. And you can change the alias name to anything you want using the armmgr command. Once you know one of the array's many names, LUN creation from HP-UX is really simple (if you didn't go ahead and make them from the VFP already).
So let's create a LUN.
armcfg -L -a -g
So, other than LUN zero, you can specify any number you want (128 on VA7100 or up to 1024 on the VA7400). The capacity can be specified in gigabytes, megabytes, or kilobytes. If you don't specify, megabytes are understood. You also need to associate the LUN with a redundancy group (more about those later). Specifying the array is lots of fun. You can use any of the five names available. Serial numbers are kind of cumbersome to type, so I tend to set a shell variable to the serial number. Or you can install an alias through armmgr and use that. Here is an example that creates a 2-gigabyte LUN number 34 on the array whose identity is in $MYARRY and associates it with redundancy group 2:
armcfg -L 34 -a 2G -g 2 $MYARRAY
Notice that a "G" follows the size. "K" specifies kilobytes and "M" tells armcfg to size on megabytes.
Now that we have a LUN, we need to make the device files. Simply run ioscan. But, do not go looking for cxt0d34. No, that would be too simple. The decimal number is converted to octal. For LUN 34, you will be looking for cxt4d2 (34 decimal is 42 octal).
To view the work you have done on the array, use armdsp. With the -i option, you get bunches of array status information. Specify -L to get all of the LUN information. Adding a LUN number as an argument to -L will limit output to that one LUN.
Just a moment ago I promised to tell you some more about redundancy groups. A VA7100 has just one redundancy group; the VA7400 has precisely two. On the VA7400, all of the disks in odd number slots are in one redundancy group and all of the even disks are in the other. Since it supports 15 disks in each unit, one of those groups is bigger than the other. Once you look at the front of yours, you will know which group has more disks (HINT: does the numbering start at zero or one?). The important thing to know about a redundancy group is that it is associated with a particular controller (and there are only two controllers). Any LUN you create is accessible from both controllers, but accessing a LUN from the other controller results in a small delay. The delays are not very big, but like anything small, they can mount up if you are not paying attention. Here is what you need to walk away from this discussion knowing: VAs don't do load balancing across controllers; you will need to take care of that by how you allocate and access the LUNs.
Since you are in charge of doling out the LUNs, you will probably be in charge of performance, too. Balancing a load on controllers is not very much fun. But, we have some proven techniques in our toolkit. One way is to alternate LUNs across the controllers and make sure the Physical Volume Link is on the alternate controller. That is not an exact science; you can still wind up with unbalanced controllers as system I/O behavior changes. Since VAs are in the category of "set it and forget it," you might want to deploy a technique that has a better chance of balancing controllers and keeping them balanced, automatically. To achieve this automatic balancing, you should allocate Logical Volumes using your favorite LVM striping mechanism interleaving the primary paths to LUNs on both controllers.
So far, configuring and managing a VA is not much different from an AutoRAID. Now we need to examine that software sprinkling. Since a VA is SAN ready, you will probably be attaching multiple hosts. By default, the VA presents all LUNs on all interfaces. Quite possibly, you do not want your NT hosts to see the LUNs the HP-UX machine is using, and vice versa. You can activate software on the VA to secure the LUNs. You get a license to manage security of up to 50 megabytes of LUNs for free; after that, you get to pay.
Here is how the security works. You build a security table on the VA that restricts the host bus adapters that have access to each LUN. Each HBA has a unique name, a worldwide name (WWN), similar to the MAC address of a NIC. Using the WWN and LUN, you build a table of who has access to what and download it to the VA. This is fairly simple stuff, so I won't go into the details. Just be careful of LUN 0 and do not disable access to the LUN from the host you are using to control the VA. If you do happen to enable a security table that locks you out, remember that you merely need to jump onto the VFP and disable security. Because they can support multiple hosts, VAs can store a boatload of data. Backups are always nice, but that Business Copy feature on the XP is enviable. No worries. With the right license loaded onto the VA, you can create and manipulate Business Copy LUNs. Again, you get access to 50 megabytes of capability for free. This feature is not all that complicated, but I am running out of column space.
With Fibre Channel interfaces, Secure Manager VA and Business Copy VA, HP SureStore Virtual Arrays have useful connectivity and management features. You can even choose the interface you want to use to manage them from HP-UX (commands, a menu system, or the full-blown graphical Command View SDM). AutoRAID has grown up some more and become bigger, faster and more manageable.
David Totsch is a Hewlett-Packard Account Support Engineer in Englewood, Colorado. He can be reached via e-mail at: david_totsch@hp.com |
|
|
