It was just last September that I wrote about Using the Dell EqualLogic HIT for Linux (HIT/LE) Version 1.0. At the time, the HIT/LE was beginning to play an important role in how we housed large volumes of data, and I wanted to share with others what I learned in the process. While it has been running well in our environment, it was definitely a 1.0 product when it came to features and configuration, so I was anxious to see what was in store for the next version. Version 1.1 was released in April of 2012, and it addressed some of the observations I had about HIT/LE 1.0. Here are a few highlights.
- Better distribution support. CentOS, the binary compatible/clone to RHEL is now supported. Versions 5.7 through 6.2 of CentOS are now supported. According to the documentation, RHEL 5.5 is no longer supported, which is a change from the previous edition. Suse Enterprise Linux is also supported.
- Auto Snapshot Manager, Linux Edition. (ASM/LE). A new feature that will allow you to create, manage, and schedule volume snapshots (Smart Copies), clones, and replicas from inside of the guest. This is huge improvement.
- A new installer and configuration process.
- Better documentation. This wasn’t listed in the release notes, but was immediately a noticeable improvement.
Version 1.0 did a good job applying the benefits of guest volumes to Linux based Operating Systems. The problem was that it left out key abilities that prevented an automated way to manage those snapshots for specific purposes. The biggest challenge I had was finding an automated way to take snapshots of these Linux guest attached volumes, and mount them to a Linux media server so that the data could be archived onto tape. No amount of glue or duct tape helped in bridging the functions needed with snapshot manipulation inside the guests.
Configuring and Connecting
The configuration and connection of volumes seems to be greatly simplified. Below demonstrates a simplified method of connecting an existing volume to a VM running the new HIT/LE 1.1. Compare this to the instructions I provided on my post about HIT/LE 1.0, and you’ll see quite a difference.
- Add access to a PS Series Group called "MYEQLGRP”
rswcli –add-group-access –gn MYEQLGRP –gip 10.10.10.100VERIFICATION: List the group added above
rswcli –l - Discover iSCSI targets
iscsiadm -m discoverydb
VERIFICATION: Confirm by viewing current list of discovered targets
iscsiadm -m node | sort –u(returns the iqn needed in the next step)
- Log into a volume name and automatically connect at boot:
ehcmcli login –target iqn.2001-05.com.equallogic:0-8a0906-3a7da1609-e720013e5c54e679-nfs100 –login-at-boot (returns the new device bound to a subdirectory below /dev/eql)VERIFICATION: Confirm device connection:
ehcmcli status - Mount it (and add to fstab for automatic mounting if desired)
mount /dev/eql/nfs100 /mnt/myexport
In-Guest Volume Snapshots (Smart Copies)
The old version of HIT/LE didn’t offer any way of creating a snapshot inside the guest. One could create volume snapshots from the Group Manager GUI, and even schedule them. However, when it came to manipulating that snapshot from a guest, such as turning it online, or connecting to it, there was no way to do so. Since the snapshots generate their own unique IQN, one needed a way to query for, and pass these variables as parameters.
The new version offers a complete command set that fills the void. At the root of the new found intelligence is the “asmcli” command. The asmcli help command will provide you with a complete listing of options. I’m not going to dive into each option, but rather, provide a simple example of how one can create a smart copy, and mount it if needed.
Before you get started, you may wish to choose or create a dedicated account on your PS Group that has volume administrator privileges. Each system that has ASM/LE installed needs an account to interact with the volumes, and this offers the least privilege necessary to interact with the Smart Copies. The example below uses an account named “asmleadmin”
- Create PS group access (one time configuration step)
asmcli create group-access –-name MYEQLGRP –-ip-address 10.10.10.100 –-user-name asmleadmin
VERIFICATION: Confirm group access is set the way you want it.
asmcli list group-access - Create Smart Copy of the guest attached volume mounted to /mnt/myexport
asmcli create smart-copy –-source /mnt/myexportVERIFICATION: List all available Smart Copies
(this will provide the object ID used in the next step)
asmcli list smart-copy –verbose 2 - Mount a Smart Copy to a temporary location of /mnt/smartcopy
asmcli mount smart-copy –-source /mnt/myexport –-object \f-f6a7e0-234b7ce30-d9c3f81bedbb96ba –-destination /mnt/smartcopy - Unmount a Smart Copy mounted in the previous step
asmcli unmount smart-copy –-object f-f6a7e0-234b7ce30-d9c3f81bedbb96ba –source /mnt/smartcopy
When documentation becomes a feature
The combination of a refined product, and improved documentation allowed for complete configuration and operation by just reading the manual. It contained real examples of commands and actions, and even a few best practices. No fumbling around due to an absence of detail or accuracy. No need to search the net or call Technical Support this time. Installation and configuration procedures reflected exactly what I experienced when testing out the new version. What a nice surprise. I wish this was more common.
More Tips for using the HIT/LE
Since my initial deployment of the HIT/LE, I had to do a fair amount of testing with these Linux systems running guest attached volumes to make sure they were satisfying performance needs; in particular, file I/O. From that testing, and observations of the systems in production, here are a few things worth noting.
- Getting data that lives on guest attached volumes onto traditional backup media does require extra thought and consideration, as traditional backup solutions that use the vCenter API can’t see these volumes. Take this into consideration when deciding use cases for guest attached volumes.
- Don’t skimp on Linux VM memory. Linux file I/O can be really impressive, but only if it has enough RAM. If you have a lot of file I/O, linux will need the RAM. I found going with anything less that 2GB of RAM had a pretty big impact on performance.
- Review the role of the Linux VM so that it can be right sized. I ran into a case where I was replacing a very important physical server with a Linux VM for our Development group, but unbeknownst to me, it was performing duties I was not aware of.
- Make sure there aren’t traditional routines that unnecessarily manipulate that data on the guest volume. This is reflected as changed block data, and could dramatically reduce the number of snaphots or replicas you can retain at any given time.
- Take a quick look at your vSwitch and port group configuration in vSphere for your guest attached volumes to make sure you are getting the most out of MPIO. Will Urban has written a great post Data Drives in VMware which addresses this topic.
In summary, the newest edition of the HIT/LE is definitely new. In fact, it feels like a complete re-write, and leaves me baffled as to why it didn’t warrant a 2.0 version designator. Nevertheless, the specific features added allow for real protection workflows to be achieved. I need to spend some more time with it to incorporate many of the new features into our environment. If you were interested in guest attached volumes in Linux, but were intimidated by the complexity of the old version, give HIT/LE 1.1 a try.
vmpete.com 