SAN | vmPete.com

Vroom! Scaling up Virtual Machines in vSphere to meet performance requirements–Part 2

March 11, 2013 3 Comments

In my original post, Scaling up Virtual Machines in vSphere to meet performance requirements, I described a unique need for the Software Development Team to have a lot of horsepower to improve the speed of their already virtualized code compiling systems. My plan of attack was simple. Address the CPU bound systems with more powerful blades, and scale up the VMs accordingly. Budget constraints axed the storage array included in my proposal, and also kept this effort limited to keeping the same number of vSphere hosts for the task.

The four new Dell M620 blades arrived and were quickly built up with vSphere 5.0 U2 (Enterprise Plus Licensing) with the EqualLogic MEM installed. A separate cluster was created to insure all build systems were kept separate, and so that I didn’t have to mask any CPU features to make them work with previous generation blades. Next up was to make sure each build VM was running VM hardware level 8. Prior to vSphere 5, the guest VM was unaware of the NUMA architecture behind it. Without the guest OS understanding memory locality, one could introduce problems into otherwise efficient processes. While I could find no evidence that the compilers for either OS are NUMA aware, I knew the Operating Systems understood NUMA.

Each build VM has a separate vmdk for its compiling activities. Their D:\ drive (or /home for Linux) is where the local sandboxes live. I typically have this second drive on a “Virtual Device Node” changed to something other than 0:x. This has proven beneficial in previous performance optimization efforts.

I figured the testing would be somewhat trivial, and would be wrapped up in a few days. After all, the blades were purchased to quickly deliver CPU power for a production environment, and I didn’t want to hold that up. But the data the tests returned had some interesting surprises. It is not every day that you get to test 16vCPU VMs for a production environment that can actually use the power. My home lab certainly doesn’t allow me to do this, so I wanted to make this count.

Testing
The baseline tests would be to run code compiling on two of the production build systems (one Linux, and the other Windows) on an old blade, then the same set with the same source code on the new blades. This would help in better understanding if there were speed improvements from the newer generation chips. Most of the existing build VMs are similar in their configuration. The two test VMs will start out with 4vCPUs and 4GB of RAM. Once the baselines were established, the virtual resources of each VM would be dialed up to see how they respond. The systems will be compiling the very same source code.

For the tests, I isolated each blade so they were not serving up other needs. The test VMs resided in an isolated datastore, but lived on a group of EqualLogic arrays that were part of the production environment. Tests were run at all times during the day and night to simulate real world scenarios, as well as demonstrate any variability in SAN performance.

Build times would be officially recorded in the Developers Build Dashboard. All resources would be observed in vSphere in real time, with screen captures made of things like CPU, disk and memory, and dumped into my favorite brain-dump application; Microsoft OneNote. I decided to do this on a whim when I began testing, but it immediately proved incredibly valuable later on as I found myself looking at dozens of screen captures constantly.

The one thing I didn’t have time to test was the nearly limitless possible scenarios in which multiple monster VMs were contending for CPUs at the same time. But the primary interest for now was to see how the build systems scaled. I would then make my sizing judgments off of the results, and off of previous experience with smaller build VMs on smaller hosts.

The [n/n] title of each test result column indicates the number of vCPUs followed by the amount of vRAM associated. Stacked bar graphs show a lighter color at the top of each bar. This indicates the difference in time between the best result and the worst result. The biggest factor of course would be the SAN.

Bottleneck cat and mouse
Performance testing is a great exercise for anyone, because it helps challenge your own assumptions on where the bottleneck really is. No resource lives as an island, and this project showcased that perfectly. Improving the performance of these CPU bound systems may very well shift the contention elsewhere. However, it may expose other bottlenecks that you were not aware of, as resources are just one element of bottleneck chasing. Applications and the Operating Systems they run on are not perfect, nor are the scripts that kick them off. Keep this in mind when looking at the results.

Test Results – Windows
The following are test results are with Windows 7, running the Visual Studio Compiler. Showing three generations of blades. The Dell M600 (HarperTown), M610, (Nehalem), and M620 (SandyBridge).

Comparing a Windows code compile across blades without any virtual resource modifications.

Yes, that is right. The old M600 blades were that terrible when it came to running VMs that were compiling. This would explain the inconsistent build time results we had seen in the past. While there was improvement in the M620 over the M610s, the real power of the M620s is that they have double the number of physical cores (16) than the previous generations. Also noteworthy is the significant impact the SAN (up to 50%) was affecting the end result.

Comparing a Windows code compile on new blade, but scaling up virtual resources

Several interesting observations about this image (above).

When the SAN can’t keep up, it can easily give back the improvements made in raw compute power.
Performance degraded when compiling with more than 8vCPUs. It was so bad that I quit running tests when it became clear they weren’t compiling efficiently (which is why you do not see SAN variability when I started getting negative returns)
Doubling the vCPUs from 4 to 8, and the vRAM from 4 to 8 only improved the build time by about 30%, even though the compile showed nearly perfect multithreading (shown below) and 100% CPU usage. Why the degradation? Keep reading!

On a different note, it was becoming quite clear already I needed to take a little corrective action in my testing. The SAN was being overworked at all times of the day, and it was impacting my ability to get accurate test results in raw compute power. The more samples I ran the more consistent the inconsistency was. Each of the M620’s had a 100GB SSD, so I decided to run the D:\ drive (where the build sandbox lives) on there to see a lack of storage contention impacted times. The purple line indicates the build times of the given configuration, but with the D:\ drive of the VM living on the local SSD drive.

The difference between a slow run on the SAN and a run with faster storage was spreading.

Test Results – Linux
The following are test results are with Linux, running the GCC compiler. Showing three generations of blades. The Dell M600 (HarperTown), M610, (Nehalem), and M620 (SandyBridge).

Comparing a Linux code compile across blades without any virtual resource modifications.

The Linux compiler showed a a much more linear improvement, along with being faster than it’s Windows counterpart. Noticeable improvements across the newer generations of blades, with no modifications in virtual resources. However, the margin of variability from the SAN is a concern.

Comparing a Linux code compile on new blade, but scaling up virtual resources

At first glance it looks as if the Linux GCC compiler scales up well, but not in a linear way. But take a look at the next graph, where similar to the experiment with the Windows VM, I changed the location of the vmdk file used for the /home drive (where the build sandbox lives) over to the local SSD drive.

This shows very linear scalability with Linux and a GCC compiler. A 4vCPU with 4GB RAM was able to compile 2.2x faster with 8vCPUs and 8GB of RAM. Total build time was just 12 minutes. Triple the virtual resources to 12/12, and it is an almost linear 2.9x faster than the original configuration. Bump it up to 16vCPUs, and diminishing returns begin to show up, where it is 3.4x faster than the original configuration. I suspect crossing NUMA nodes and the architecture of the code itself was impacting this a bit. Although, don’t lose sight of the fact that a build that could take up to 45 minutes on the old configuration took only 7 minutes with 16vCPUs.

The big takeaways from these results are the differences in scalability in compilers, and how overtaxed the storage is. Lets take a look at each one of these.

The compilers
Internally it had long been known that Linux compiled the same code faster than Windows. Way faster. But for various reasons it had been difficult to pinpoint why. The data returned made it obvious. It was the compiler.

While it was clear that the real separation in multithreaded compiling occurred after 8vCPUs, the real problem with the Windows Visual Studio compiler begins after 4vCPUs. This surprised me a bit because when monitoring the vCPU usage (in stacked graph format) in vCenter, it was using every CPU cycle given to it, and multithreading quite evenly. The testing used Visual Studio 2008, but I also tested newer versions of Visual Studio, with nearly the same results.

Storage
The original proposal included storage to support the additional compute horsepower. The existing set of arrays had served our needs very well, but were really targeted at general purpose I/O needs with a focus of capacity in mind. During the budget review process, I had received many questions as to why we needed a storage array. Boiling it down to even the simplest of terms didn’t allow for that line item to survive the last round of cuts. Sure, there was a price to pay for the array, but the results show there is a price to pay for not buying the array.

I knew storage was going to be an issue, but when contention occurs, its hard to determine how much of an impact it will have. Think of a busy freeway, where throughput is pretty easy to predict up to a certain threshold. Hit critical mass, and predicting commute times becomes very difficult. Same thing with storage. But how did I know storage was going to be an issue? The free tool provided to all Dell EqualLogic customers; SAN HQ. This tool has been a trusted resource for me in the past, and removes ALL speculation when it comes to historical usage of the arrays, and other valuable statistics. IOPS, read/write ratios, latency etc. You name it.

Historical data of Estimated Workload over the period of 1 month

Historical data of Estimated Workload over the period of 12 months

Both images show that with the exception of weekends, the SAN arrays are maxed out to 100% of their estimated workload. The overtaxing shows up on the lower part of each screen capture the read and writes surpassing the brown line indicating the estimated maximum IOPS of the array. The 12 month history showed that our storage performance needs were trending upward.

Storage contention and how it relates to used CPU cycles is also worth noting. Look at how inadequate storage I/O influences compute. The image below shows the CPU utilization for one of the Linux builds using 8vCPUs and 8GB RAM when the /home drive was using fast storage (the local SSD on the vSphere host)

Now look at the same build when running against a busy SAN array. It completely changes the CPU usage profile, and thus took 46% longer to complete.

General Observations and lessons

If you are running any hosts using pre-Nehalem architectures, now is a good time to question why. They may not be worth wasting vSphere licensing on. The core count and architectural improvements on the newer chips put the nails in the coffin on these older chips.
Storage Storage Storage. If you have CPU intensive operations, deal with the CPU, but don’t neglect storage. The test results above demonstrate how one can easily give back the entire amount of performance gains in CPU by not having storage performance to support it.
Giving a Windows code compiling VM a lot of CPU, but not increasing the RAM seemed to make the compiler trip on it’s own toes. This makes sense, as more CPUs need more memory addresses to work with.
The testing showcased another element of virtualization that I love. It often helps you understand problems that you might otherwise be blind to. After establishing baseline testing, I noticed some of the Linux build systems were not multithreading the way they should. Turns out it was some scripting errors by our Developers. Easily corrected.

Conclusion
The new Dell M620 blades provided an immediate performance return. All of the build VMs have been scaled up to 8vCPUs and 8GB of RAM to get the best return while providing good scalability of the cluster. Even with that modest doubling of virtual resources, we now have nearly 30 build VMs that when storage performance is no longer an issue, will run between 4 and 4.3 times faster than the same VMs on the old M600 blades. The primary objective moving forward is to target storage that will adequately support these build VMs, as well as looking into ways to improve multithreaded code compiling in Windows.

Helpful Links
Kitware blog post on multithreaded code compiling options

http://www.kitware.com/blog/home/post/434

Filed under Architecture/planning, SAN, virtualization, VMware Tagged with code compiling, Monster VMs, NUMA, vCPU, vSphere

Diagnosing a failed iSCSI switch interconnect in a vSphere environment

October 6, 2012 4 Comments

The beauty of a well constructed, highly redundant environment is that if a single point fails, systems should continue to operate without issue. Sometimes knowing what exactly failed is more challenging than it first appears. This was what I ran into recently, and wanted to share what happened, how it was diagnosed, and ultimately corrected.

A group of two EqualLogic arrays were running happily against a pair of stacked Dell PowerConnect 6224 switches, serving up a 7 node vSphere cluster. The switches were rebuilt over a year ago, and since that time they have been rock solid. Suddenly, the arrays started spitting out all kinds of different errors. Many of the messages looked similar to these:

iSCSI login to target ’10.10.0.65:3260, iqn.2001-05.com.equallogic:0-8a0906-b6cc21609-d200014832f4ecfb-vmfs001′ from initiator ’10.10.0.10:52155, iqn.1998-01.com.vmware:esx1-70a98577′ failed for the following reason:
Initiator disconnected from target during login.

Some of the earliest errors on the array looked like this:

10/1/2012 1:01:11 AM to 10/1/2012 1:01:11 AM
Warning: Member PS6000e network port cannot be reached. Unable to obtain network performance data for the member.
Warning: Member PS6100e network port cannot be reached. Unable to obtain network performance data for the member.
10/1/2012 1:01:11 AM to 10/1/2012 1:01:11 AM
Caution: Some SNMP requests to member PS6100e for disk drive information timed out.
Caution: Some SNMP requests for information about member PS6100e disk drives timed out.

VMs that had guest attached volumes were generating errors similar to this:

Subject: ASMME smartcopy from SVR001: MPIO Reconfiguration Request IPC Error – iqn.2001-05.com.equallogic:0-8a0906-bd5d27503-7ef000ed5d54a8c1-ntfs001 on host SVR001

[01:01:11] MPIO failure during reconfiguration request for target iqn.2001-05.com.equallogic:0-8a0906-476f6bd06-0c500008a0c4c41f-ntfs002 with error status 0×16000000.

[01:01:11] MPIO failure during reconfiguration request for target iqn.2001-05.com.equallogic:0-8a0906-dc0da1609-2fe0014145f4e931-ntfs001 with error status 0×80070006.

Before I had a chance to look at anything, I suspected something was wrong with the SAN switch stack, but was uncertain beyond that. I jumped into vCenter to see if anything obvious showed up. But vSphere and all of the VMs were motoring along just like normal. No failed uplink errors, or anything else noticeable. I didn’t do much vSphere log fishing at this point because all things were pointing to something on the storage side, and I had a number of tools that could narrow down the problem. With all things related to storage traffic, I wanted to be extra cautious and prevent making matters worse with reckless attempts to resolve.

First, some background on how EqualLogic arrays work. All arrays have two controllers, working in an active/passive arrangement. Depending on the model of array, each controller will have between two and four ethernet ports per controller, with each port having an IP address assigned to it. Additionally, there will be a single IP address to define the “group” the member array is a part of. (The Group IP is single IP used by systems looking for an iSCSI target, to let the intelligence of the arrays figure out how to distribute traffic across interfaces.) If some of the interfaces can’t be contacted (e.g. disconnected cable, switch failure, etc.), the EqualLogic arrays will be smart enough to distribute across the active links.

The ports of each EqualLogic array are connected to the stacked SAN switches in a meshed arrangement for redundancy. If there ware a switch failure, then one wouldn’t be able to contact the IP addresses of the ethernet ports connected to one of the switches. But using a VM with guest attached volumes (which have direct access to the SAN), I could successfully ping all four interfaces (eth0 through eth3) on each array. Hmm…

So then I decided to SSH into the array and see if I could perform the same test. The idea would be to test from one IP on one of the arrays to see if a ping would be successful on eth0 through eth3 on the other array. The key to doing this is to use an IP of one of the individual interfaces as the source, and not the Group IP. Controlling the source and the target during this test will tell you a lot. After connecting to the array via SSH, the syntax for testing the interfaces on the target array would be this:

ping –I “[sourceIP] [destinationIP]” (quotes are needed!)

From one of the arrays, pinging all four interfaces on the second array revealed that only two of the four ports succeeded. But the earlier test from the VM proved that I could ping all interfaces, so I chose to change the source IP as one of the interfaces living on the other switch. Performed the same test, and the opposite results occurred. The ports that failed on the last test passed on this test, and the ports that passed the last test, failed on this time. This seemed to indicate that both switches were up, but the communication between switches were down.

While I’ve never seen these errors on switches using stacking modules, I have seen the MPIO errors above on a trunked arrangement. One might run into these issues more with trunking, as it tends to leave more opportunity for issues caused by configuration errors. I knew that in this case, the switch configurations had not been touched for quite some time. The status of the switches via the serial console stated the following:

SANSTACK>show switch
Management Standby Preconfig Plugged-in Switch Code
SW Status Status Model ID Model ID Status Version
1 Mgmt Sw PCT6224 PCT6224 OK 3.2.1.3
2 Unassigned PCT6224 Not Present 0.0.0.0

The result above wasn’t totally surprising, in that if the stacking module was down, the master switch wouldn’t be able to be able to gather the information from the other switch.

Dell also has an interesting little tool call “Lasso.” The Dell Lasso Tool will help grab general diagnostics data from a variety of sources (servers, switches, storage arrays). But in this case, I found it convenient to test connectivity from the array group itself. The screen capture below seems to confirm what I learned through the testing above.

So the next step was trying to figure out what to do about it. I wanted to reboot/reload the slave switch, but knowing both switches were potentially passing live data, I didn’t want to do anything to compromise the traffic. So I employed an often overlooked, but convenient way of manipulating traffic to the arrays; turning off the interfaces on the array that are connected to the SAN switch that needs to be restarted. If one turns off the interfaces on each array connected to the switch that needs the maintenance, then there will not be any live data passing through that switch. Be warned that you better have a nice, accurate wiring schematic of your infrastructure so that you know which interfaces can be disabled. You want to make things better, not worse.

After a restart of the second switch, the interconnect reestablished itself. The interfaces on the arrays were re-enabled, with all errors disappearing. I’m not entirely sure why the interconnect went down, but the primary objective was diagnosing and correcting in a safe, deliberate, yet speedy way. No VMs were down, and the only side effect of the issue was the errors generated, and some degraded performance. Hopefully this will help you in case you see similar symptoms in your environment.

Helpful Links

Dell Lasso Tool

http://www.dell.com/support/drivers/us/en/555/DriverDetails?driverId=4T3Y6&c=us&l=en&s=biz

Reworking my PowerConnect 6200 switches for my iSCSI SAN

http://vmpete.com/2011/06/26/reworking-my-powerconnect-6200-switches-for-my-iscsi-san/

Dell TechCenter. A great resource all things related to Dell in the Enterprise.

http://en.community.dell.com/techcenter/b/techcenter/default.aspx

Filed under Architecture/planning, SAN, virtualization Tagged with Powerconnect

Multipathing in vSphere with the Dell EqualLogic Multipathing Extension Module (MEM)

September 20, 2012 22 Comments

There is a lot to be said about the Dell EqualLogic Multipathing Extension Module (MEM) for vSphere. One is that it is an impressive component that without a doubt will improve the performance of your vSphere environment. The other is that it often not installed by organizations large and small. This probably stems from a few reasons.

The typical user is uncertain of the value it brings.
vSphere Administrators might be under the assumption that VMware’s Round Robin will perform the same thing.
The assumption that if they don’t have vSphere Enterprise Plus licensing, they can’t use MEM.
It’s command line only

What a shame, because the MEM gives you optimal performance of vSphere against your EqualLogic array, and is frankly easier to configure. Let me clarify, easier to configure correctly. iSCSI will work seemingly okay with not much effort. But that lack of effort initially can catch up with you later; resulting in no multipathing, poor performance, and possibly prone to error.

There are a number of good articles that outline the advantages of using the MEM. There is no need for me to repeat, so I’ll just stand on the shoulder’s of their posts, and provide the links at the end of my rambling.

The tool can be configured in a number of different ways to accommodate all types of scenarios; all of which is well documented in the Deployment Guide. The flexibility in deployment options might be why it seems a little intimidating to some users.

I’m going to show you how to set up the MEM in a very simple, typical fashion. Let’s get started. We’ll be working under the following assumptions:

vSphere 5 and the EqualLogic MEM *
An ESXi host Management IP of 192.168.199.11
Host account of root with a password of mypassword
a standard vSwitch for iSCSI traffic will be used with two physical uplinks (vmnic4 & vmnic5) The vSwitch created will be a standard vSwitch, but it can easily be a Distributed vSwitch as well.
Three IP addresses for each host; two for iSCSI vmkernels (192.168.198.11 & 192.168.198.21), and one for Storage Heartbeat. (192.168.198.31)
Jumbo frames (9000 bytes) have been configured on your SAN switchgear, and will be used on your ESXi hosts.
A desire to accommodate VMs that used guest attached volumes.
EqualLogic Group IP address of: 192.168.198.65
Storage network range of 192.168.198.0 /24

When applying to your environment, just tailor the settings to reflect your environment.

Download and preparation

1. Download the MEM from the Dell EqualLogic customer web portal to a workstation that has the vSphere CLI installed

2. Extract the MEM so that it resides in a C:\MEM directory. You should see a setup.pl file in the root of C:\MEM, along with a dell-eql-mem-esx5-[version].zip Keep this zip file, as it will be needed during the installation process.

Update ESXi host

1. Put ESXi host in Maintenance Mode

2. Delete any previous vSwitch that goes into the pNICs for iSCSI. Will also need to remove any previous port bindings.

3. Initiate script against first host:

setup.pl –configure –server=192.168.199.11 –username=root –password=mypassword

This will walk you through a series of variables you need to enter. It’s all pretty straightforward, but I’ve found the more practical way is to include it all as one string. This minimizes mistakes, improves documentation, and allows you to just cut and paste into the vSphere CLI. The complete string would look like this.

setup.pl –configure –server=192.168.199.11 –vswitch=vSwitchISCSI –mtu=9000 –nics=vmnic4,vmnic5 –ips=192.168.198.11,192.168.198.21 –heartbeat=192.168.198.31 –netmask=255.255.255.0 –vmkernel=iSCSI –nohwiscsi –groupip=192.168.198.65

It will prompt for a user name and password before it runs through the installation. Near the end of the installation, it will return:

No Dell EqualLogic Multipathing Extension Module found. Continue your setup by installing the module with the ‘esxcli software vib install’ command or through vCenter Update Manager

This is because the MEM VIB has not been installed yet. MEM will work but only using the default pathing policies. The MEM VIB can be installed by typing in the following:

setup.pl –install –server=192.168.199.11 –username=root –password=mypassword

If you look in vCenter, you’ll now see the vSwitch and vmkernel ports created and configured properly, with the port bindings configured correctly as well. You can verify it with the following

setup.pl –query –server=192.168.199.11 –username=root –password=mypassword

But you aren’t quite done yet. If you are using guest attached volumes, you will need to create Port Groups on that same vSwitch so that the guest volumes can connect to the array. To do it properly in which the two vNICs inside the guest OS can multipath to the volume properly, you will need to create two Port Groups. When complete, your vSwitch may look something like this:

Take a look at the VMkernel ports created by MEM, you will see the NIC Teaming Switch Failover Order has been set so that one vmnic is set to “Active” while the other is set to “Unused” The other VMkernel port has the same settings, but with the vmnics reversed in their “Active” and “Unused” state.The Port Groups you create for VMs using Guest attached volumes will take a similar approach. Each Port Group will have one “Active” and one “Standby” adapter (“Standby” not “unused” like the VMkernel). Each Port Group has the vmnics reversed. When configuring a VM’s NICs for guest attached volume access, you will want to assign one vmnic to one Port Group, while the other is assigned to the other Port Group. Confused? Great. Take a look at Will Urban’s post on how to configure Port Groups for guest attached volumes correctly.

Adjusting your existing environment.
If you need to rework your existing setup, simply put each host into Maintenance Mode one at a time and perform the steps above with your appropriate information.Next, take a look at your existing Datastores, and if they are using one of the built in Path Selection Policy methods (“Fixed” “Round Robin” etc.), change them over to “DELL_PSP_EQL_ROUTED”If you have VMs that leverage guest attached volumes off of a single teamed Port Group, you may wish to temporarily create this Port Group under the exact same name so the existing VMs have don’t get confused. Remove this temporary Port Group once you’ve had the opportunity to change the VM’s properties.So there you have it. A simple example of how to install and deploy Dell’s MEM for vSphere 5. Don’t leave performance and ease of management on the shelf. Get MEM installed and running in your vSphere environment.

UPDATE (9/25/2012)
The instructions provided was under the assumption that vSphere 5 was being used. Under vSphere 5.1 and the latest version of MEM, the storage heartbeat is no longer needed. I have modified the post to accommodate, including the link below that references the latest Dell EqualLogic MEM documentation. I’d like to thank the Dell EqualLogic Engineering team for pointing out this important distinction.

Helpful Links

A great summary on the EqualLogic MEM and vStorage APIs

http://whiteboardninja.wordpress.com/2011/02/01/equallogic-mem-and-vstorage-apis/

Comac Hogan’s great post on how the MEM works it’s magic.

http://blogs.vmware.com/vsphere/2011/11/dells-multipath-extension-module-for-equallogic-now-supports-vsphere-50.html

Some performance testing of the MEM

http://www.spoonapedia.com/2010/07/dell-equallogic-multipathing-extension.html

Official Documentation for the EqualLogic MEM (Rev 1.2, which covers vSphere 5.1)

http://www.equallogic.com/WorkArea/DownloadAsset.aspx?id=11000

Filed under Architecture/planning, SAN, virtualization Tagged with MEM, Multipathing Extension Module

Dell EqualLogic’s newest Host Integration Tools for Linux (v1.1)

May 28, 2012 1 Comment

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

VERIFICATION: 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/myexport
VERIFICATION: List all available Smart Copies
asmcli list smart-copy –verbose 2

(this will provide the object ID used in the next step)
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.

Filed under Replication, SAN, virtualization Tagged with EqualLogic, HIT Tools, vSphere 5.0

VDI for me. Part 5 – The wrap up

March 29, 2012 2 Comments

Now that VMware View is up and running, you might be curious to know how it is working. Well, you’re in luck, because this post is about how View worked, and what was learned from this pilot project. But first, here is a quick recap of what has been covered so far.

VDI for me. Part 1 – Why the interest
VDI for me. Part 2 – The Plan
VDI for me. Part 3 – Firewall considerations
VDI for me. Part 4 – Connection Servers and tuning

I was given the opportunity to try VMware View for a few different reasons (found here). I wasn’t entirely sure what to expect, but was determined to get a good feel for what VDI in 2012 could do. Hopefully this series has helped you gain an understanding as well.

The user experience
Once things were operational, the ease and ubiquity of access to the systems was impressive. One of our most frequent users often stated that he simply forgot where the work was actually being performed. Comments like that are a good indicator of success. From a remote interaction standpoint, the improvements most often showed up where it was really needed; remote display over highly latent connections, with convenience of access. Being able to access a remote system from behind one corporate network to another was as productive as it was cool.

It was interesting to observe how some interpreted the technology. Some embraced it for what it was (an appliance to be more productive), while others chose to be more suspicious. You may have users who complain about their existing computers, but are apprehensive at the notion of it being taken away for something that isn’t tangible. Don’t underestimate this emotional connection between user and computer. It’s a weird, but very real aspect of a deployment like this.

Virtualization Administrators know that good performance is often a result of a collection of components (storage, network, CPU, hypervisor) working well together through a good design. Those of us who have virtualized our infrastructures are accustomed to this. Users are not. As VMs become more exposed to the end users (whether they be for VDI, or other user-facing needs), your technical users may become overly curious by what’s “under the hood” with their VM. This can be a problem. Comparisons between their physical machine and the VM are inevitable, and they may interpret a VM with half the processors and RAM as their physical machine to provide only half of the experience. You might even be able to demonstrate that the VM is indeed better performing in many ways, yet the response might be that they still don’t have enough RAM, CPU, etc. The end user knows nothing about hypervisors or IOPS, but they will pay attention to some of the common specifications general consumers of technology have been taught to care about; RAM and CPUs.

So in other words, there will be aspects of a project like this that have everything to do with virtualization, yet nothing to do with virtualization. It can be as much of a people issue as it is a technical issue.

Other Impressions
The PCoIP protocol is very nice, and really shines in certain situations. I love the fact that it is a tunable, non-connection oriented protocol that leaves all of the rendering up to the host. It just makes so much sense for remote displays. But it can have characteristics that make it feel different to the end user. The old “window shake” test might redraw itself slightly different than in a native display, or using something like RDP. This is something that the user may or may not notice.

The pilot program included the trial of a PCoIP based Zero Client. The Wyse P20 didn’t disappoint. Whether it was connecting to a VM brokered by View, or a physical workstation with a PCoIP host card brokered by View, the experience was clean and easy. Hook up a couple of monitors to it, and turn it on. It finds the connection server, so all you need to do is enter your credentials, and you are in. The zero client was limited to just PCoIP, so if you need flexibility in that department, perhaps a thin client might be more appropriate for you. I wanted to see what no hassle was really like.

As far as feedback, the top three questions I usually received from users went something like this:

“Does it run on Linux?”

“How come it doesn’t run on Linux?”

“When is it going to run on Linux?”

And they weren’t just talking about the View Client (which as of this date will run on Ubuntu 11.04), but more importantly, the View Agent. There are entire infrastructures out there that use frameworks and solutions that run on nothing but Linux. This is true especially in arenas like Software Development, CAE and Scientific communities. Even many of VMware’s offerings are built off of frameworks that have little to do with Windows. The impression that the supported platforms of View gave to our end users was that VMware’s family of solutions were just Windows based. Most of you reading this know that simply isn’t true. I hope VMware takes a look at getting View agents and clients out for Linux.

Serving up physical systems using View as the connection broker is an interesting tangent to the whole VDI experience. But of course, this is a one user to one workstation arrangement – its just that the workstation isn’t stuffed under a desk somewhere. I suspect that VMware and its competitors are going to have to tackle the problem of how to harness GPU power through the hypervisor so that all but the most demanding of high end systems can be virtualized. Will it happen with specialized video cards likely to come from the VMware/NVIDIA partnership announced in October of 2011? Will it happen with some sort of SR-IOV? The need for GPU performance is there. How it will be a achieved, I don’t know. In the short term, if you need big time GPU power, a physical workstation with a PCoIP host card will work fine.

The performance and wow factor of running a View VM on a tablet is high as well. If you want to impress anyone, just show this setup on a tablet. Two or three taps on the tablet and you are in. But we all know that User Experience (UX) designs for desktop applications were meant for a large screen, mouse, and a keyboard. It will be interesting to see how the evolution of these technologies continue, so that UX can hit mobile devices in a more appropriate way. Variations of application virtualization is perhaps the next step. Again, another exciting unknown.

Also a worthwhile note is competition, not only in classically defined VDI solutions, but access to systems. A compelling aspect of using View is that it pairs a solution for remote display, and brokering secure remote access into one package. But other competing solutions do not necessarily have to take that approach. Microsoft’s “Direct Access” allows for secure RDP sessions to occur without a traditional VPN. I have not had an opportunity yet to try their Unified Access Gateway (UAG) solution, but it gets rave reviews from those who implement it, and use it. Remote Desktop Session Host (RDSH) in Windows Server 8 promises big things (if you only use Windows of course).

Among the other challenges is how to implement such technologies in a way that is cost effective. Up front costs associated with going beyond a pilot phase might be a bit tough to swallow, as technical challenges such as storage I/O deserve attention. I suspect with the new wave of SSD and SSD hybrid SAN arrays out there, that it might make the technical and financial challenges more palatable. I wish that I had the opportunity to demonstrate how well these systems would work on an SSD or hybrid array, but the word “pilot” typically means “keep the costs down.” So no SSD array until we move forward with a larger deployment.

There seems to be a rush by many to take a position on whether VDI is the wave of the future, or a bust that will never happen. I don’t think its necessary to think that way. It is what it is; a technology that might benefit you or the business you work for, or it might not. What I do know is that it is rewarding and fun to plan and deploy innovative solutions that help end users, while addressing classic challenges within IT. This was one of those projects.

Those who have done these types of implementations will tell you that successful VDI implementations always pay acute attention to the infrastructure, especially storage. (Reading about failed implementations seems to confirm this). I believe it. I was almost happy that my licensing forced me to keep this deployment small, as I could focus on the product rather than some of the implications with storage I/O that would inevitably come up with a larger deployment. Economies of scale makes VDI intriguing in deployment and operation. However, it appears to be that scaling is the tricky part.

What might also need a timely update is Windows licensing. There is usually little time left in the day to understand the nuances of EULAs in general – especially Windows licensing. VDI adds an extra twist to this. A few links at the end of this post will help explain why.

None of these items above discount the power and potential of VDI. While my deployments were very small, I did get a taste of its ability to consolidate corporate assets back to the data center. The idea of provisioning, maintaining, and protecting end user systems seems possible again, and in certain environments could have a profound improvement. It is easy to envision smaller branch office greatly reducing, or eliminating servers at their location. AD designs simplify. Assets simplify, as does access control – all with providing a more flexible work environment. Not a bad combination.

Thanks for reading.

Helpful Links:
Two links on Windows 7 SPLA and VDI

http://www.brianmadden.com/blogs/brianmadden/archive/2011/03/02/why-microsoft-hates-vdi.aspx

http://www.brianmadden.com/blogs/gabeknuth/archive/2012/03/09/gasp-turns-out-onlive-really-isn-t-in-compliance-with-microsoft-licensing.aspx

RDSH in Windows Server 2008

http://searchvirtualdesktop.techtarget.com/tip/RDSH-and-RemoteFX-in-Windows-Server-8-to-improve-VDI-user-experience

VDI has little to do with the Desktop

http://whiteboardninja.wordpress.com/2011/01/24/planning-for-vdi-has-little-to-do-with-the-desktop/

Scott Lowe’s interesting post on SR-IOV

http://blog.scottlowe.org/2012/03/19/why-sr-iov-on-vsphere/

Improving density of VMs per host with Teradici’s PCoIP Offload card for VMware View

http://www.teradici.com/pcoip/pcoip-products/teradici-apex-2800.php

Filed under Architecture/planning, SAN, VDI, virtualization, VMware View Tagged with PCoIP, View

Tips for using Dell’s updated EqualLogic Host Integration Tools – VMware Edition (HIT/VE)

November 17, 2011 15 Comments

Ever since my series of posts on replication with a Dell EqualLogic SAN, I’ve had a lot of interest from other users wondering how I actually use the built-in tools provided by Dell EqualLogic to protect my environment. This is one of the reasons why I’ve written so much about ASM/ME, ASM/LE, and SANHQ. Well, it’s been a while since I’ve touched on any information about ASM/VE, and since I’ve updated my infrastructure to vSphere 5.0 and the HIT/VE 3.1, I thought I’d share a few pointers that have helped me work with this tool in my environment.

The first generation of HIT/VE was really nothing more than a single tool referred to as “Auto-Snapshot Manager / VMware Edition” or ASM/VE. A lot has changed, as it is now part of a larger suite of VMware-centric tools from EqualLogic called the Host Integration Tools / VMware Edition or HIT/VE. This consists of the following; EqualLogic Auto-Snapshot Manager, EqualLogic Datastore Manager, and the EqualLogic Virtual Desktop Deployment Utility. HIT/VE is one of three Host Integration toolsets. The others being HIT/ME and HIT/LE for Microsoft and Linux respectively.

Ever since HIT/VE 3.0, Dell EqualLogic thankfully transitioned toward and appliance/plug-in model. This reduced overhead, complexity, and removed some of the quirks with the older implementations. Because I had been lagging behind in updating vSphere, I was still using 2.x up until recently, and skipped right over 3.0 to 3.1. Surprisingly, many of the same practices that have served me well with the older version adopt quite well to the new version.

Let me preface that these are just my suggestions off of personal use with all versions of the HIT over the past 3 years. Just as with any solution, there are a number of different ways to achieve the same result. The information provided may or may not align with best practices from Dell, or your own practices. But the tips I provide have stood up to the rigors of a production environment, and have actually worked in real recovery scenarios. Whatever decisions you make should compliment your larger protection strategies, as this is just one piece of the puzzle.

Tips for Configuring and working with the HIT/VE appliance

1. The initial configuration will ask for registration in vCenter (configuration item #8 on the appliance). You may only register one HIT/VE appliance in vCenter.

2. The HIT/VE appliance was designed to integrate with vCenter. But it also offers the flexibility of access. After the initial configuration, you can verify and modify settings in the respective ASM appliances by browsing directly to their IP address, FQDN, or DNS alias name. You may type in: http://%5BapplianceFQDN%5D or for the Auto-Snapshot Manager, type in http://%5BapplianceFQDN%5D/vmsnaptool.html

3. Configuration of the storage management network on the appliance is optional, and depending on your topology, may not be needed.

4. When setting up replication partners, ASM will ask for a “Server URL” This implies you should enter an “http://” or “https://” Just enter in the IP address or FQDN without the http:// prefix. A true URL as it implies will not work.

5. After you have configured your HIT/VE appliances, run back through and double check the settings. I had two of them mysteriously reset some DNS configuration during the initial deployment. It’s been fine since that time. It might have been my mistake (twice), but it might not.

6. For just regular (local) SmartCopies, create one HIT/VE appliance. Have the appliance sit in its own small datastore. Make sure you do not protect this volume via ASM. Dell warns you about this. For environments where replication needs to occur, set up a second HIT/VE appliance at the remote site. The same rules apply there.

7. Log files on the appliance are accessible via Samba. I didn’t discover this until I was working through the configuration and some issues I was running into. What a pleasant way to to pull the log data off of the appliance. Nice work!

Tips for ASM/VE

8. Just as I learned and recommended in 2.x, the most important suggestion I have to successfully utilizing ASM/VE in your environment is to arrange vCenter folders to represent the contents of your datastores. Include in the name some indicated of the referencing volume/datastore (seen in the screen capture below, where “103” refers to a datastore called VMFS103. The reason for this is so that you can keep your smartcopy snapshots straight during creation. If you don’t do this, when you make a SmartCopy of a folder containing VM’s that reside in multiple datastores, you will see SAN snapshots in each one of those volumes, but they didn’t necessarily capture all of the data correctly. You will get really confused, and confusion is not what you need when understanding the what and how of recovering systems or data.

9. Schedule or manually create SmartCopy Snapshots by Folder. Schedule or manually create SmartCopy Replicas by dataStore. Replicas cannot be created by vCenter Folder. This strategy has been the most effective for me, but if you didn’t feel like re-arranging your folders in vCenter, you could schedule or manually create SmartCopy Snapshots by datastore as well.

10. Do not schedule or create Smartcopies by individual machine. This will get confusing (see above), and may interfere with your planning of snapshot retention periods. If you want to protect a system against some short term step (e.g. installing service pack, etc.), just use a hypervisor snapshot, and remove when complete.

11. ASM/VE 2.x was limited to making smart copies of VM’s that had vmdk files all in the same location. 3.x does not have this limitation. This offers up quite a bit of flexibility if you have VM’s with independent vmdks in other datastores.

12. Test, and document. Create a couple of small volumes, large enough to hold 2 test VM’s in each. Make a SmartCopy of the VMWare folder where those VM’s reside. Do a few more SmartCopies, then attempt a restore. Test. Add a vmdk in another datastore to one of the VM’s then test again. This is the best way to not only understand what is going on, but to have no surprises or trepidation when you have to do it for real. It is especially important to understand how the other VM’s in the same datastore will behave, and how VM’s with multiple vmdks in different datastores will act, as well as what a “restore by rollback” is. And while you’re add it, make a OneNote or Word document outlining the exact steps for recovery, and what to expect. Create one for local SmartCopies, and another for remote replicas. This avoids not thinking clearly under the heat of the moment. Your goal is to make things better by a restore, not worse. Oh, and if you can’t find the time to document the process, don’t worry, I’m sure the next guy who replaces you will find the time.

13. Set snapshot and replication retention numbers in ASM/VE. This much needed feature was added to the 3.0 version. Tweak each snapshot reserve to a level that you feel comfortable with, and that also matches up against your overall protection policies. There will be some tuning for each volume so that you can offer the protection times needed, without allocating too much space to snapshot reserves. ASM will only be able to manage the snapshots that it creates, so if you have some older snaps of a particular datastore, you may need to do a little cleanup work.

14. Watch the frequency!!! The only thing worse than not having a backup of a system or data, is to have several bad copies of it, and to realize that the last good one just purged itself out. A great example of this is something going wrong on a Friday night. You maybe don’t notice it mid-day on Monday. But your high frequency SmartCopies only had room for two days worth of changed data. With ASM/VE, I tend to prefer very modest frequencies. Once a day is fine with me on many of my systems. Most of the others that I like to have more frequent SmartCopies of have the actual data on guest attached volumes. Early on in my use, I had a series of events that were almost disastrous, all because I was overzealous on the frequency, but not mindful enough of the retention. Don’t be a victim of the ease at cranking up the frequency at the expense of retention. This is something you’ll never find in a deployment or operations guide, and applies to all aspects of data protection.

15. If you are creating SmartCopy snapshots and SmartCopy replicas, use your scheduling an opportunity to shrink the window of vulnerability. Instead of running a replica right after a snapshot each once a day, right after eachother, split the difference so that the replica runs in between the the last SmartCopy snapshot, and the next one.

16. Keep your SmartCopy and replica frequencies and scheduling as simple as possible. If you can’t understand it, who will? Perhaps start with a frequency rate of just once a day for all of your datastores, then go from there. You might find a frequency such as once a day might work for 99% of your systems. I’ve found that for most of my data that I need to protect at more frequent intervals, those are on guest attached volumes anyway, and I schedule those up via ASM/ME to meet my needs.

17. For SmartCopy snapshots, I tend to schedule them so that there is only one job on one datastore at a time. With the next one scheduled say 5 minutes afterward. For SmartCopy replicas, if you choose to use free pool space, instead of replica reserve (as I do), you might want to offset those more, so that the replica has time to fully complete in order for the space held by the invisible local replica can be reclaimed for the next job. Generally this isn’t too much of an issue, unless you are really tight on space.

18. The SmartCopy defaults have been changed a bit since ASM/VE 2.x. No need to tick any of the checkboxes such as “Perform virtual machine memory dump” and “Set created PS Series snapshots online” In fact, I would untick the “Included PS Series volumes access by guest iSCSI initiators” More info on why below.

19. ASM/VE still gives you the option to snapshot volumes that are attached to that VM via guest iSCSI initiators. In general, don’t do it. Why? If you chose to use this option for Microsoft based VM’s, it would indeed make a snapshot, giving you the impression that all is well, but these would not be coordinated with the internal VSS writer inside the VM, so they are not truly application consistent snapshots of the guest volumes. Sure, they might work, but they might not. They may also interfere with your retention policies in ASM/ME. Do you really want to take that chance with your Exchange or SQL databases, or flat file storage? If you think flat file storage isn’t important to quiesce, remember that source code control systems like Subversion typically use file systems, and not a database. It is my position that the only time you should use this option is if you are protecting a Linux VM with guest attached volumes. Linux has no equivalent to VSS, so you get a free pass on using this option. However, because this option is a per-job definition, you’ll want to separate Windows based VM’s with guest volumes from Linux based VM’s with guest volumes. If you wanted to avoid that, you could just rely on on a crash consistent copy of that linux guest attached volume via a scheduled snapshot in the Group Manager GUI. So the moral of the story is this. To protect your guest attached volumes in VM’s running Windows, rely entirely on ASM/ME to create a SmartCopy SAN snapshot of your guest attached volumes.

20. If you need to cherry-pick a file off of a snapshot, or look at an old registry setting, consider restoring or cloning to another volume, and make sure that the restored VM does not have any direct access to the same network that the primary system is running. Having a special portgroup in vCenter that is just for this purpose works nice. Many times this method can be the least disruptive to your environment.

21. I still like to have my DC’s in individual datastores, on their own, and create SmartCopy schedules that do not occur simultaneously. I found that in practice, our very sensitive automated code compiling system which has dozens (if not hundreds) of active ssh sessions ran into less interference this way compared to when I initially had them in one datastore, or intertwined in datastores with other VMs. Depending on the number of DCs you have, you might be able to group a couple together, with perhaps splitting off the DC running the PDC emulator role into a separate datastore. Beware that the SmartCopy for your DC should just be considered as a way to protect the system, not AD. More info on my post about protecting Active Directory here.

Tips for DataStore Manager

22. The Datastore Manager in vCenter is one of my favorite new ways to view my PS Group. Not only do you get a quick check on how my datastores look (limiting the view to just VMFS volumes), but it also shows which volumes have replicas in flight. It has quickly become one of my most used items in vCenter.

23. Use the ACL policies feature in Datastore Manager. With the new integration between vCenter and the Group Manager, you can easily create volumes. The ACL policies feature in the HITVE is a way for you to save a predetermined set of ACL’s for your hosts (CHAP, IP, or IQN). While I personally prefer using IQN’s, any combination of the three will work. Having an ACL policy is a great way to provision the access to a volume quickly. If you are using manually configured multi-pathing, it is important to note that creating datastores by this way will using a default pathing of “VMWare fixed.” You will need to manually change that to “VMWare Round Robin.” I am told that if you are using the EqualLogic Multi-pathing Extension Module (MEM), that this will be set to the proper setting. I don’t know that for sure because MEM hasn’t been released for vSphere 5.0 as of this writing.

24. VMFS5 offers some really great features, but many of them are only available if they were natively created (not upgraded from VMFS3). If you choose to recreate them by doing a little juggling with Storage vMotion (as I am), remember that this might wreak havoc on your replication, as you will need to re-seed the volumes. But if you can, you are exposed to many great features of VMFS5. You might also use this as an opportunity to revisit your datastores and re-arrange if necessary.

25. If you are going to redo some of your volumes from scratch (to take full advantage of VMFS5), if they are replicated, redo the volumes with the highest change rate first. They’re already pushing a lot of data through your pipe, so you might as well get them taken care of first. And who knows, your replicas might be improved with the new volume.

Hopefully this gives you a few good ideas for your own environment. Thanks for reading.

Filed under SAN, virtualization Tagged with ASM/VE, HIT/VE

Upgrading to vSphere 5.0 by starting from scratch. …well, sort of.

November 11, 2011 2 Comments

It is never any fun getting left behind in IT. Major upgrades every year or two might not be a big deal if you only had to deal with one piece of software, but take a look at most software inventories, and you’ll see possibly dozens of enterprise level applications and supporting services that all contribute to the chaos. It can be overwhelming for just one person to handle. While you may be perfectly justified in holding off on specific upgrades, there still seems to be a bit of guilt around doing so. You might have ample business and technical factors to support such decisions, and a well crafted message providing clear reasons to stakeholders. The business and political pressures ultimately win out, and you find yourself addressing the more customer/user facing application upgrades before the behind-the-scenes tools that power it all.

That is pretty much where I stood with my virtualized infrastructure. My last major upgrade was to vSphere 4.0. Sure, I had visions of keeping up with every update and patch, but a little time passed, and several hundred distractions later, I found myself left behind. When vSphere 4.1 came out, I also had every intention of upgrading. However, I was one of the legions of users who had a vCenter server running on a 32bit OS, and that complicated matters a little bit. I looked at the various publications and posts on the upgrade paths and experiences. Nothing seemed quite as easy as I was hoping for, so I did what came easiest to my already packed schedule; nothing. I wondered just how many Administrators found themselves in the same predicament; not touching an aging, albeit perfectly fine running system.

My ESX 4.0 cluster served my organization well, but times change, and so do needs. A few things come up to kick-start the desire to upgrade.

I needed to deploy a pilot VDI project, fast. (more about this in later posts)
We were a victim of our own success with virtualization, and I needed to squeeze even more power and efficiency out of our investment in our infrastructure.

Both are pretty good reasons to upgrade, and while I would have loved to do my typical due diligence on every possible option, I needed a fast track. My move to vSphere 5.0 was really just a prerequisite of sorts to my work with VDI.

But how should I go about an upgrade?

Do I update my 4.0 hosts to the latest update that would be eligible for an upgrade path to 5.0, and if so, how much work would that be? Should I transition to a new vCenter server, migrating the database, then run a mixed environment of ESX hosts running with different versions? What sort of problems would that introduce? After conferring with a trusted colleague of mine who always seems to have pragmatic sensibilities when it comes to virtualization, I decided which option was going to be the best for me. I opted not to do any upgrade, and simply transition to a pristine new cluster. It looked something like this:

Take a host (either new, or by removing an existing one from the cluster), and build it up with ESXi 5.0.
Build up a new 64bit VM for running a brand new vCenter, and configure as needed.
Remove one VM at a time from the old cluster by powering them down, remove from inventory, add to the new cluster.
Once enough VM’s have been removed, take another host, remove from the old cluster, rebuild as ESXi 5.0, and add to the new cluster.
Repeat until finished.

For me, the decision to start from scratch won out. Why?

I could build up a pristine vCenter server, with a database that wasn’t going to carry over any unwanted artifacts of my previous installation.
I could easily set up the new vCenter to emulate my old settings. Folders, EVC settings, resource pools, etc.
I could transition or build up my supporting VM’s or appliances to my new infrastructure to make sure they worked before committing to the transition.
I could afford a simple restart of each VM as I transitioned it to a new cluster. I used this as an opportunity to update the VMware Tools when added to the new inventory.
I was willing to give up historical data in my old vSphere 4.0 cluster for the sake of simplicity of the plan and cleanliness of the configuration.
Predictability. I didn’t have to read a single white paper or discussion thread on database migrations or troubles with DSNs.
I have a well documented ESX host configuration that is not terribly complex, and easy to recreate across 6 hosts.
I just happened to have purchased an additional blade and license of ESX, so it was an ideal time to introduce it to my environment.
I could get my entire setup working, then get my licensing figured out after it’s all complete.

You’ll notice that one option similar to this approach would have been to simply remove a host of running VM’s out of the existing cluster, and add it to the new cluster. This may have been just as good of a plan, as it would have avoided the need to manually shut down and remove each VM one at a time during the transition. However, I would have needed to run a mix of ESX 4.0 and 5.0 hosts in the new cluster. I didn’t want to carry anything over from the old setup. I would have needed to upgrade or rebuild the host anyway, and I had to restart each VM to make sure it was running the latest tools. If for nothing other than clarity of mind, my approach seemed best for me.

Prior to beginning the transition, I needed to update my Dell EqualLogic firmware to 5.1.2. A collection of very nice improvements made this a nice upgrade, but a requirement for what I wanted to do. While the upgrade itself went smoothly, it did re-introduce an issue or two. The folks at Dell EqualLogic are aware of this, and are working to address it hopefully in their next release. The combination of the firmware upgrade, and vSphere 5 allowed me to use the latest and greatest tools from EqualLogic, primarily the Host Integration Tools VMWare Edition (HIT/VE) and the storage integration in vSphere thanks to VASA. Although, as of this writing, EqualLogic does not have a full production release of their MultiPathing Extension Module (MEM) for vSphere 5.0. The EPA version was just released, but I’ll probably wait for the full release of MEM to come out before I apply it to the hosts in the cluster.

While I was eager to finish the transition, I didn’t want to prematurely create any problems. I took a page from my own lessons learned during my upgrade to ESX 4.0, and exercised some restraint when it came to updating my Virtual Hardware for each VM to version 8. My last update of Virtual Hardware levels in each VM caused some unexpected results, as I shared in “Side effects of upgrading VM’s to Virtual Hardware 7 in vSphere” Apparently, I wasn’t the only one who ran into issues, because that post has statistically been my all time most popular post. The abilities of Virtual Hardware 8 powered VMs are pretty neat, but I’m in no rush to make any virtual hardware changes to some of my key production systems, especially those noted.

So, how did it work out? The actual process completed without a single major hang-up, and am thrilled with the result. The irony here is that even though vSphere provides most of the intelligence behind my entire infrastructure, and does things that are mind bogglingly cool, it was so much easier to upgrade than say, SharePoint, AD, Exchange, or some other enterprise software. Great technologies are great because they work like you think they should. No exception here. If you are considering a move to vSphere 5.0, and are a little behind on your old infrastructure, this upgrade approach might be worth considering.

Now, onto that little VDI project…

Resources

A great resource on setting up SQL 2008 R2 for vCenter
How to Install Microsoft SQL Server 2008 R2 for VMware vCenter 5

Installing vCenter 5 Best Practices

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2003790

A little VMFS 5.0 info

http://www.yellow-bricks.com/2011/07/13/vsphere-5-0-what-has-changed-for-vmfs/

Information on the EqualLogic Multipathing Extension Module (MEM), and if you are an EqualLogic customer, why you should care.

https://whiteboardninja.wordpress.com/2011/02/01/equallogic-mem-and-vstorage-apis/

Filed under Architecture/planning, SAN, virtualization Tagged with vCenter, vSphere 5.0

Using the Dell EqualLogic HIT for Linux

September 6, 2011 3 Comments

I’ve been a big fan of Dell EqualLogic Host Integration Tools for Microsoft (HIT/ME), so I was looking forward to seeing how the newly released HIT for Linux (HIT/LE) was going to pan out. The HIT/ME and HIT/LE offer unique features when using guest attached volumes in your VM’s. What’s the big deal about guest attached volumes? Well, here is why I like them.

It keeps the footprint of the VM really small. The VM can easily fit in your standard VMFS volumes.
Portable/replaceable. Often times, systems serving up large volumes of unstructured data are hard to update. Having the data as guest attached means that you can easily prepare a new VM presenting the data (via NFS, Samba, etc.), and cut it over without anyone knowing – especially when you are using DNS aliasing.
Easy and fast data recovery. My “in the trenches” experience with the guest attached volumes in VM’s running Microsoft OS’s (and EqualLogic’s HIT/ME) have proven that recovering data off of guest attached volumes is just easier – whether you recover it from snapshot or replica, clone it for analysis, etc.
Better visibility of performance. Thanks to the independent volume(s), one can easily see with SANHQ what the requirements of that data volume is.
More flexible protection. With guest attached volumes, it’s easy to crank up the frequency of snapshot and replica protection on just the data, without interfering with the VM that is serving up the data.
Efficient, tunable MPIO.
Better utilization of space. If you wanted to serve up a 2TB volume of storage using a VMDK, more than likely you’d have a 2TB VMFS volume, and something like a 1.6TB VMDK file to accommodate hypervisor snapshots. With a native volume, you would be able to use the entire 2TB of space.

The one “gotcha” about guest attached volumes is that they aren’t visible by the vCenter API, so commercial backup applications that rely on the visibility of these volumes via vCenter won’t be able to back them up. If you use these commercial applications for protection, you may want to determine if guest attached volumes are a good fit, and if so, find alternate ways of protecting the volumes. Others might contend that because the volumes aren’t seen by vCenter, one is making things more complex, not less. I understand the reason for thinking this way, but my experience with them have proven quite the contrary.

Motive
I wasn’t trying out the HIT/LE because I ran out of things to do. I needed it to solve a problem. I had to serve up a large amount (several Terabytes) of flat file storage for our Software Development Team. In fact, this was just the first of several large pools of storage that I need to serve up. It would have been simple enough to deploy a typical VM with a second large VMDK, but managing such an arrangement would be more difficult. If you are ever contemplating deployment decisions, remember that simplicity and flexibility of management should trump simplicity of deployment if it’s a close call. Guest attached volumes align well with the “design as if you know it’s going to change” concept. I knew from my experience with working with guest attached volumes for Windows VM’s, that they were very agile, and offered a tremendous amount of flexibility.

But wait… you might be asking, “If I’m doing nothing but presenting large amounts of raw storage, why not skip all of this and use Dell’s new EqualLogic FS7500 Multi-Protocol NAS solution?” Great question! I had the opportunity to see the FS7500 NAS head unit at this year’s Dell Storage Forum. The FS7500 turns the EqualLogic block based storage accessible only on your SAN network into CIFS/NFS storage presentable to your LAN. It is impressive. It is also expensive. Right now, using VM’s to present storage data is the solution that fits within my budget. There are some downfalls (Samba not supporting SMB2), but for the most part, it falls in the “good enough” category.

I had visions of this post focusing on the performance tweaks and the unique abilities of the HIT/LE. After implementing it, I was reminded that it was indeed a 1.0 product. There were enough gaps in deployment information that I felt it necessary to provide information on exactly how I actually made the HIT for Linux work. IT Generalists who I suspect make up a significant amount of the Dell EqualLogic customer base have learned to appreciate their philosophy of “if you can’t make it easy, don’t add the feature.” Not everything can be made intuitive however, especially the first time around.

Deployment Assumptions
The scenario and instructions are for a single VM that will be used to serve up a single large volume for storage. It could serve up many guest attached volumes, but for the sake of simplicity, we’ll just be connecting to a single volume.

VM with 3 total vNICs. One used for LAN traffic, and the other two, used exclusively for SAN traffic. The vNIC’s for the SAN will be assigned to the proper vswitch and portgroup, and will have static IP addresses. The VM name in this example is “testvm”
A single data volume in your EqualLogic PS group, with an ACL that allows for the guest VM to connect to the volume using CHAP, IQN, or IP addresses. (It may be easiest to first restrict it by IP address, as you won’t be able to determine your IQN until the HIT is installed). The native volume name in this example is “nfs001” and the group IP address is 10.1.0.10
Guest attached volume will be automatically connected at boot, and will be accessible via NFS export. In this example I will be configuring the system so that the volume is available via the “/data1” directory.
OS used will be RedHat Enterprise Linux (RHEL) 5.5.
EqualLogic’s HIT 1.0

Each step below that starts with word “VERIFICATION” is not a necessary step, but it helps you understand the process, and will validate your findings. For brevity, I’ve omitted some of the output of these commands.

Deploying and configuring the HIT for Linux
Here we go…

Prepping for Installation

1. Verify installation of EqualLogic prerequisites (via rpm -q [pkgname]). If not installed, run yum install [pkgname]

openssl (0.9.8e for RHEL 5.5)

libpcap (0.9.4 for RHEL 5.5)

iscsi-initiator-utils (6.2.0.871 for RHEL 5.5)

device-mapper-multipath (0.4.7 for RHEL 5.5)

python (2.4 for RHEL 5.5.)

dkms (1.9.5 for RHEL 5.5)

(dkms is not part of RedHat repo. Need to download from
http://linux.dell.com/dkms/
or via the "Extra Packages for LInux" epel repository. I chose Dell website location because it was a newer version. Simply download and execute RPM.).

2. Snapshot Linux machine so that if things go terribly wrong, it can be reversed

3. Shutdown VM, and add NIC’s for guest access

Make sure to choose iSCSI network when adding to VM configuration

After startup, manually specify Static IP addresses and subnet mask for both. (No default gateway!)

Activate NIC’s, and reboot

4. Power up, then add the following lines to /etc/sysctl.conf (for RHEL 5.5)

net.ipv4.conf.all.arp_ignore = 1

net.ipv4.conf.all.arp_announce = 2

5. Establish NFS and related daemons to automatically boot

chkconfig portmap on

chkconfig nfs on

chkconfig nfslock on

6. Establish directory which will ultimately be used to export for mounting. In this example, the iSCSI device will mount to a directory called “eql2tbnfs001” in the /mnt directory.

mkdir /mnt/eql2tbnfs001

7. Make symbolic link called “data1” in the root of the file system.

ln -s /mnt/eql2tbnfs001 /data1

Installation and configuration of the HIT

8. Verify that the latest HIT Kit for Linux is being used for installation. (V1.0.0 as of 9/2011)

9. Import public key

Download the public key from eql support site under HIT for Linux, and place in /tmp/ )

Add key:

rpm –import RPM-GPG-KEY-DELLEQL (docs show lower case, but file is upper case)

10. Run installation

yum localinstall equallogic-host-tools-1.0.0-1.e15.x86_64.rpm

Note: After HIT is installed, you may get the IQN for use of restricting volume access in the EqualLogic group manager by typing the following:

cat /etc/iscsi/initiatorname.iscsi.

11. Run eqltune (verbose). (Tip. You may want to capture results to file for future reference and analysis)

eqltune -v

12. Make adjustments based on eqltune results. (Items listed below were mine. Yours may be different)

NIC Settings

Flow Control.

ethtool -A eth1 autoneg off rx on tx on

ethtool -A eth2 autoneg off rx on tx on

(add the above lines to /etc/rc.d/rc.local to make persistent)

There may be a suggestion to use jumbo frames by increasing the MTU size from 1500 to 9000. This has been omitted from the instructions, as it requires proper configuration of jumbos from end to end. If you are uncertain, keep standard frames for the initial deployment.

iSCSI Settings

(make backup of /etc/iscsi/iscid.conf before changes)

Change node.startup to manual.

node.startup = manual

Change FastAbort to the following:

node.session.iscsi.FastAbort = No

Change initial_login_retry to the following:

node.session.initial_login_retry_max = 12

Change number of queued iSCSI commands per session

node.session.cmds_max = 1024

Change device queue depth

node.session.queue_depth = 128

13. Re-run Eqltune -v to see if changes took affect

All changes took effect, minus the NIC settings added to the rc.local file. Looks to be a syntax error from Eql documentation provided. It has been corrected in the documentation above.

14. Run command to view and modify MPIO settings

rswcli –mpio-parameters

This returns the results of: (seems to be good for now)

Processing mpio-parameters command…

MPIO Parameters:

Max sessions per volume slice:: 2

Max sessions per entire volume:: 6

Minimum adapter speed:: 1000

Default load balancing policy configuration: Round Robin (RR)

IOs Per Path: 16

Use MPIO for snapshots: Yes

Internet Protocol: IPv4

The mpio-parameters command succeeded.

15. Restrict MPIO to just the SAN interfaces

Exclude LAN traffic

rswcli -E -network 192.168.0.0 -mask 255.255.255.0

VERIFICATION: List status of includes/excludes to verify changes

rswcli –L

VERIFICATION: Verify Host connection Mgr is managing just two interfaces

ehcmcli –d

16. Discover targets

iscsiadm -m discovery -t st -p 10.1.0.10

(Make sure no unexpected volumes connect. But note the IQN name presented. You’ll need it for later.)

VERIFICATION: shows iface

[root@testvm ~]# iscsiadm -m iface | sort

default tcp,<empty>,<empty>,<empty>,<empty>

eql.eth1_0 tcp,00:50:56:8B:1F:71,<empty>,<empty>,<empty>

eql.eth1_1 tcp,00:50:56:8B:1F:71,<empty>,<empty>,<empty>

eql.eth2_0 tcp,00:50:56:8B:57:97,<empty>,<empty>,<empty>

eql.eth2_1 tcp,00:50:56:8B:57:97,<empty>,<empty>,<empty>

iser iser,<empty>,<empty>,<empty>,<empty>

VERIFICATION: Check connection sessions via iscsiadm -m session to show that no connections exist

[root@testvm ~]# iscsiadm -m session

iscsiadm: No active sessions.

VERIFICATION: Check connection sessions via /dev/mapper to show that no connections exist

[root@testvm ~]# ls -la /dev/mapper

total 0

drwxr-xr-x 2 root root 60 Aug 26 09:59 .

drwxr-xr-x 10 root root 3740 Aug 26 10:01 ..

crw——- 1 root root 10, 63 Aug 26 09:59 control

VERIFICATION: Check connection sessions via ehcmcli -d to show that no connections exist

[root@testvm ~]# ehcmcli -d

17. Login just one of the iface paths of your liking (shown in red here). Replace the IQN here (shown in green) with yours. The HIT will take care of the rest.

iscsiadm -m node -T iqn.2001-05.com.equallogic:0-8a0906-451da1609-2660013c7c34e45d-nfs001 -I eql.eth1_0 -l

This returned:

[root@testvm ~]# iscsiadm -m node -T iqn.2001-05.com.equallogic:0-8a0906-451da1609-2660013c7c34e45d-nfs001 -I eql.eth1_0 -l

Logging in to [iface: eql.eth1_0, target: iqn.2001-05.com.equallogic:0-8a0906-451da1609-2660013c7c34e45d-nfs001, portal: 10.1.0.10,3260]

Login to [iface: eql.eth1_0, target: iqn.2001-05.com.equallogic:0-8a0906-451da1609-2660013c7c34e45d-nfs001, portal: 10.1.0.10,3260] successful.

VERIFICATION: Check connection sessions via iscsiadm -m session

[root@testvm ~]# iscsiadm -m session

tcp: [1] 10.1.0.10:3260,1 iqn.2001-05.com.equallogic:0-8a0906-451da1609-2660013c7c34e45d-nfs001

tcp: [2] 10.1.0.10:3260,1 iqn.2001-05.com.equallogic:0-8a0906-451da1609-2660013c7c34e45d-nfs001

VERIFICATION: Check connection sessions via /dev/mapper. This is going to give you the string you will need to use making and mounting the filesystem.

[root@testvm ~]# ls -la /dev/mapper

VERIFICATION: Check connection sessions via ehcmcli -d

[root@testvm ~]# ehcmcli -d

18. Make new file system from the dm-switch name. Replace the IQN here (shown in green) with yours. If this is an existing volume that has been used before (from a snapshot, or another machine) there is no need to perform this step. Documentation will show this step without the “-j” switch, which will format it as a non-journaled ext2 file system. The –j switch will format it as an ext3 file system.

mke2fs -j -v /dev/mapper/eql-0-8a0906-451da1609-2660013c7c34e45d-nfs001

19. Mount the device to a directory

[root@testvm mnt]# mount /dev/mapper/eql-0-8a0906-451da1609-2660013c7c34e45d-nfs001 /mnt/eql2tbnfs001

20. Establish iSCSI connection automatically

[root@testvm ~]# iscsiadm -m node -T iqn.2001-05.com.equallogic:0-8a0906-451da1609-2660013c7c34e45d-nfs001 -I eql.eth1_0 -o update -n node.startup -v automatic

21. Mount volume automatically

Change /etc/fstab, adding the following:

/dev/mapper/eql-0-8a0906-451da1609-2660013c7c34e45d-nfs001 /mnt/eql2tbnfs001 ext3 _netdev 0 0

Restart system to verify automatic connection and mounting.

Working with guest attached volumes
After you have things configured and operational, you’ll see how flexible guest iSCSI volumes are to work with.

Do you want to temporarily mount a snapshot to this same VM or another VM? Just turn the snapshot online, and make a connection inside the VM.
Do you need to archive your data volume to tape, but do not want to interfere with your production system? Mount a recent snapshot of the volume to another system, and perform the backup there.
Do you want to do a major update to that front end server presenting the data? Just build up a new VM, connect the new VM to that existing data volume, and change your DNS aliasing, (which you really should be using) and you’re done.
Do you need to analyze the I/O of the guest attached volumes? Just use SANHQ. You can easily see if that data should be living on some super fast pool of SAS drives, or a pool of PS4000e arrays. You’ll be able to make better purchasing decisions because of this.

So, how did it measure up?

The good…
Right out of the gate, I noticed a few really great things about the HIT for Linux.

The prerequisites and installation. No compiling or other unnecessary steps. The installation package installed clean with no fuss. That doesn’t happen every day.
Eqltune. This little utility is magic. Talk about reducing overhead in preparing a system for MPIO and all things related to guest based iSCSI volumes. It gave me a complete set of adjustments to make, divided into 3 simple categories. After I made the adjustments, I re-ran the utility, everything checked out okay. Actually, all of the command line tools were extremely helpful. Bravo!
One really impressive trait of the HIT/LE is how it handles the iSCSI sessions for you. Session build up and teardown is all taken care of by the HIT for Linux.

The not so good…
Almost as fast as the good shows up, you’ll notice a few limitations

Version 1.0 is only officially supported on RedHat Enterprise Linux (RHEL) 5.5 and 6.0 (no 6.1 as of this writing). This might be news to Dell, but Debian based systems like Ubuntu are running in enterprises everywhere for it’s cost, solid behavior, and minimalist approach. RedHat clones dominate much of the market; some commercial, and some free. Personally, upstream Distributions such as Fedora are sketchy, and prone to breakage with each release (Note to Dell, I don’t blame you for not supporting these. I wouldn’t either). Other distributions are quirky for their own reasons of “improvement” and I can understand why these weren’t initially supported either. A safer approach for Dell (and the more flexible approach for the customer) would be to 1.) Get out a version for Ubuntu as fast as possible, and 2.) Extend the support of this version to RedHat’s, downstream, 100% binary compatible, very conservative distribution, CentOS. For you Linux newbies, think of CentOS as being the RedHat installation but with the proprietary components stripped out, and nothing else added. While my first production Linux server running the HIT is RedHat 5.5, all of my testing and early deployment occurred on a CentOS 5.5 Distribution, and it worked perfectly.
No AutoSnapshot Manager (ASM) or equivalent. I rely on ASM/ME on my Windows VM’s with guest attached volumes to provide me with a few key capabilities. 1.) A mechanism to protect the volumes via snaphots and replicas. 2.) Coordinating applications and I/O so that I/O is flushed properly. Now, Linux does not have any built-in facility like Microsoft’s Volume Shadow Copy Services (VSS), so Dell can’t do much about that. But perhaps some simple script templates might give the users ideas on how to flush and pause I/O of the guest attached volumes for snapshots. Just having a utility to create Smart copies or mount them would be pretty nice.

The forgotten…
A few things overlooked? Yep.

I was initially encouraged by the looks of the documentation. However, In order to come up with the above, I had to piece together information from a number of different resources. Syntax and capitalization errors will kill you in a Linux shell environment. Some of those inconsistencies and omissions showed up. With a little triangulation, I was able to get things running correctly, but it quickly became a frustrating, time consuming exercise that I felt like I’ve been through before. Hopefully the information provided here will help.
Somewhat related to the documentation issue is something that has come up with a few of the other EqualLogic tools; Customers often don’t understand WHY one might want to use the tool. Same thing goes with the HIT for Linux. Nobody even gets to the “how” if they don’t understand the “why”. But, I’m encouraged by the great work the Dell TechCenter has been doing with their white papers and videos. It has become a great source for current information, and are moving in the right direction of customer education.

Summary
I’m generally encouraged by what I see, and am hoping that Dell EqualLogic takes on the design queues of the HIT/ME to employ features like AutoSnapshot Manager, and an equivalent to eqlxcp (EqualLogic’s offloaded file copy command in Windows). The HIT for Linux helped me achieve exactly what I was trying to accomplish. The foundation for another easy to use tool in the EqualLogic line up is certainly there, and I’m looking forward to how this can improve.

Helpful resources
Configuring and Deploying the Dell EqualLogic Host Integration Toolkit for Linux

http://en.community.dell.com/dell-groups/dtcmedia/m/mediagallery/19861419/download.aspx

Host Integration Tools for Linux – Installation and User Guide

https://www.equallogic.com/support/download_file.aspx?id=1046
(login required)

Getting more IOPS on workloads running RHEL and EQL HIT for Linux

http://en.community.dell.com/dell-blogs/enterprise/b/tech-center/archive/2011/08/17/getting-more-iops-on-your-oracle-workloads-running-on-red-hat-enterprise-linux-and-dell-equallogic-with-eql-hitkit.aspx

RHEL5.x iSCSI configuration (Not originally authored by Dell, nor specific to EqualLogic)

http://www.equallogic.com/resourcecenter/assetview.aspx?id=8727

User’s experience trying to use the HIT on RHEL 6.1, along with some other follies

http://www.linux.com/community/blogs/configuring-dell-equallogic-ps6500-array-to-work-with-redhat-linux-6-el.html

Dell TechCenter website

http://DellTechCenter.com/

Dell TechCenter twitter handle
@DellTechCenter

Filed under SAN, virtualization Tagged with ASM/ME, ASM/VE, EqualLogic, ESX, HIT Tools

vmPete.com

Vroom! Scaling up Virtual Machines in vSphere to meet performance requirements–Part 2

Diagnosing a failed iSCSI switch interconnect in a vSphere environment

Multipathing in vSphere with the Dell EqualLogic Multipathing Extension Module (MEM)

Dell EqualLogic’s newest Host Integration Tools for Linux (v1.1)

VDI for me. Part 5 – The wrap up

Tips for using Dell’s updated EqualLogic Host Integration Tools – VMware Edition (HIT/VE)

Upgrading to vSphere 5.0 by starting from scratch. …well, sort of.

Using the Dell EqualLogic HIT for Linux

Pages

Search

Tweets

Follow me...

Recent Posts

Top Posts

Seattle VMUG user blogs

Tags

Archives

Follow “vmPete.com”