VMware ESX, NIC Teaming, and VLAN Trunking with HP ProCurve

Found this great article and thought I would share it with RH readers:

Original text from http://blog.scottlowe.org/

In an earlier article about VMware ESX, NIC teaming, and VLAN trunking, I described what the configuration should look like if one were using these features with Cisco switch hardware. It’s been a quite popular post, one I will probably need to update soon.

In this article, I’d like to discuss how to do the same thing, but using HP ProCurve switch hardware. The article is broken into three sections: using VLANs, using link aggregation (NIC teaming), and using both together.
Using VLAN Trunking

To my Cisco-oriented mind, VLANs with ProCurve switches are handled quite differently. Port-based VLANs, in which individual ports are assigned to one or more VLANs, allow a switch port to participate in that VLAN as either an untagged fashion or in a tagged fashion.

The difference here is really simpler than it may seem: the untagged VLAN can be considered the “native VLAN” from the Cisco world, meaning that the VLAN tags are not added to packets traversing that port. Putting a port in a VLAN in untagged mode is essentially equivalent to making that port an access port in the Cisco IOS world. Only one VLAN can be marked as untagged, which makes sense if you think about it.

Any port groups that should receive traffic from the untagged VLAN need to have VLAN ID 0 (no VLAN ID, in other words) assigned.

A tagged VLAN, on the other hand, adds the 802.1q VLAN tags to traffic moving through the port, like a VLAN trunk. If a user wants to use VST (virtual switch tagging) to host multiple VLANs on a single VMware ESX host, then the ProCurve ports need to have those VLANs marked as tagged. This will ensure that the VLAN tags are added to the packets and that VMware ESX can direct the traffic to the correct port group based on those VLAN tags.

In summary:

* Assign VLAN ID 0 to all port groups that need to receive traffic from the untagged VLAN (remember that a port can only be marked as untagged for a single VLAN). This correlates to the discussion about VMware ESX and the native VLAN, in which I reminded users that port groups intended to receive traffic for the native VLAN should not have a VLAN ID specified.
* Be sure that ports are marked as tagged for all other VLANs that VMware ESX should see. This will enable the use of VST and multiple port groups, each configured with an appropriate VLAN ID. (By the way, if users are unclear on VST vs. EST vs. VGT, see this article.)
* VLANs that VMware ESX should not see at all should be marked as “No” in the VLAN configuration of the ProCurve switch for those ports.

Using Link Aggregation

There’s not a whole lot to this part. In the ProCurve configuration, users will mark the ports that should participate in link aggregation as part of a trunk (say, Trk1) and then set the trunk type. Here’s the only real gotcha: the trunk must be configured as type “Trunk” and not type “LACP”.

In this context, LACP refers to dynamic LACP, which allows the switch and the server to dynamically negotiate the number of links in the bundle. VMware ESX doesn’t support dynamic LACP, only static LACP. To do static LACP, users will need to set the trunk type to Trunk.

Then, as has been discussed elsewhere in great depth, configure the VMware ESX vSwitch’s load balancing policy to “Route based on ip hash”. Once that’s done, everything should work as expected. This blog entry gives the CLI command to set the vSwitch load balancing policy, which would be necessary if configuring vSwitch0. For all other vSwitches, the changes can be made via VirtualCenter.

That’s really all there is to making link aggregation work between an HP ProCurve switch and VMware ESX.
Using VLANs and Link Aggregation Together

This section exists only to point out that when a trunk is created, the VLAN configuration for the members of that trunk disappears, and the trunk must be configured directly for VLAN support. In fact, users will note that the member ports don’t even appear in the list of ports to be configured for VLANs; only the trunks themselves appear.

Key point to remember: apply your VLAN configurations after your trunking configuration, or else you’ll just have to do it all over again.

With this information, users should now be pretty well prepared to configure HP ProCurve switches in a VMware ESX environment. Feel free to post any questions, clarifications, or corrections in the comments below, and thanks for reading!

ZFS Performance Testing: Dell PowerEdge 2950 III

In my previous post on ZFS performance testing I ran through various tests on a particular test system that I had running at the time. That system has come and gone to a better place in the proverbial cloud. This go round, I have a similar server with a different ZFS configuration. Lets dive in to the system and tests.

Test rig:

  • Dell PowerEdge 2950
  • Xeon Quad Core 1.6GHz
  • 8GB RAM
  • PERC5 – Total of 5 logical drives with read ahead and write back enabled.
  • 2x160GB SATAII 7200 RPM – Hardware RAID1
  • 4x2TB SATAII 7200 RPM – Four (4) Hardware RAID0’s (Controller does not support JBOD mode)
  • FreeNAS 0.7.2 Sabanda (revision 5543)-ZFS v13

GNU dd:
Tests performed from the CLI using good ole’ GNU dd. The following command was used to first write, and then read back:

dd if=/dev/zero of=foo bs=2M count=10000 ; dd if=foo of=/dev/null bs=2M

Results:
Results are listed as configuration, write, then read.

  • Reference run: 2x160GB 7200 RPM SATAII RAID1
    • 85.6 MB/s
    • 92.5 MB/s

  • ZFS stripe pool utilizing two (2) SATA disks
    • 221 MB/s
    • 206 MB/s

  • ZFS stripe pool utilizing two (2) SATA disks with dataset compression set to “On”
    • 631 MB/s
    • 1074 MB/s

  • ZFS mirror pool utilizing two (2) SATA disks
    • 116 MB/s
    • 145 MB/s

  • ZFS mirror pool utilizing two (2) SATA disks with dataset compression set to “On”
    • 631 MB/s
    • 1069 MB/s
  • Notes, Thoughts & Mentionables:
    There are a few things worth mentioning about this system:
    On the hard disk side of things, the hardware RAID1 was made up of Western Digital Blue disks while the other four (4) disks are Western Digital 2TB Green drives. If you have done your home work, you already know that the WD EARS disks use 4K sectors and masks this as 512byte sectors so that OS’ don’t complain. If disks are not properly formatted and/or sector aligned with this in mind, performance takes a tremendous hit. The reason for such inexpensive disks for this build is simple: This server is configured as a backup destination and as such, size is more important than the reliability that a SAS solution would provide.

    Compressions test results were, to say the least, quite interesting. It should be noted that the stripe and mirror pools performed quite similarly. Further testing of these results will be required, but it seems that the maximum score of 1074 MB/s was limited only by the CPU. During the read test all four cores of the quad core CPU were maxed. This becomes even more interesting when you compare the results of this two disk stripe pool with my previous findings on the six disk stripe pool running the same test. The earlier test rig scored much lower and it would appear to be the difference in CPUs that made such a strong difference.

    –himuraken

ZFS Performance Testing: Dell PowerEdge 2900

***Update***
This started a simple post to share a few results from various levels of zfs/array testing. Be sure to check back from time to time as I add additional configuration results.

***Begin Original Text***
I have been playing around with ZFS on various operating systems lately and have been trying to compare performance. I figured that sharing some of my results would give others something to compare with. Plus, I am on borrowed time with this unit, it is big, loud, and taking up free space and spare time in the home office.

Test rig:

  • Dell PowerEdge 2900
  • Xeon Dual Core 3.0GHz (HT Enabled-OS showing 4 cores)
  • 14GB RAM
  • PERC5 – Total of 7 logical drives with read ahead and write back enabled.
  • 2x146GB SAS 15K RPM – Hardware RAID1 for OS
  • 6x1TB SATAII 7200 RPM – Six (6) SATAII 7200 RPM Disks for testing. (Controller does not support JBOD mode)
  • FreeNAS 0.7.2 Sabanda (revision 5543)-ZFS v13

GNU dd:
Tests performed from the CLI using good ole’ GNU dd. The following command was used to first write, and then read back:

dd if=/dev/zero of=foo bs=2M count=10000 ; dd if=foo of=/dev/null bs=2M

Results: Each disk configured as a separate RAID0 array on controller.
Results are listed as configuration, write, then read.

  • ZFS raidz1 pool utilizing six (6) SATA disks
    • 133 MB/s
    • 311 MB/s

  • ZFS raidz1 pool utilizing six (6) SATA disks with dataset compression set to “On”
    • 414 MB/s
    • 359 MB/s

  • ZFS raidz2 pool utilizing six (6) SATA disks
    • 180 MB/s
    • 286 MB/s

  • ZFS raidz2 pool utilizing six (6) SATA disks with dataset compression set to “On”
    • 414 MB/s
    • 361 MB/s

  • ZFS stripe pool utilizing six (6) SATA disks
    • 190 MB/s
    • 263 MB/s

  • ZFS stripe pool utilizing six (6) SATA disks with dataset compression set to “On”
    • 429 MB/s
    • 381 MB/s
  • Results: Each disk configured as a member of a single RAID0 array.
    Results are listed as configuration, write, then read.

    • ZFS stripe pool utilizing six (6) SATA disks
      • 353.4 MB/s
      • 473.0 MB/s

    • ZFS stripe pool utilizing six (6) SATA disks with dataset compression set to “On”
      • 420.8 MB/s
      • 340.9 MB/s
    • Results: Each disk configured as a member of a single RAID5 array.
      Results are listed as configuration, write, then read.

      • ZFS stripe pool utilizing six (6) SATA disks
        • 322.0 MB/s
        • 325.9 MB/s

      • ZFS stripe pool utilizing six (6) SATA disks with dataset compression set to “On”
        • 438.8x MB/s
        • 371.8 MB/s
      • Results: Each disk configured as a member of a single RAID10 array.
        Results are listed as configuration, write, then read.

        • ZFS stripe pool utilizing six (6) SATA disks
          • 251.2 MB/s
          • 304.3 MB/s

        • ZFS stripe pool utilizing six (6) SATA disks with dataset compression set to “On”
          • 430.7 MB/s
          • 360.9 MB/s
        • Notes, Thoughts & Mentionables:
          It is worth noting that the results of the datasets with compression on can be a bit misleading. This is due to the source we are using with dd; /dev/zero. Feeding a string of zeroes into a compression algorithm is probably the best case scenario when it comes to compression. In real world conditions, data being read or written that is compressible would experience an increase in performance, while non-compressible data would likely suffer a penalty.

          I am hoping to conduct the same tests on the exact hardware in the near future. I will be switching the six (6) SATA disks over to varying hardware RAID levels and comparing them again.

          ***Update***
          In a follow-up post to this one, I concluded that compression read and write performance on this particular test rig was being limited by the CPU. I am hoping to swap out the current Intel Xeon 3.0GHz dual core for a quad core for additional comparison.

          –himuraken

VMUG: Tech Data in Clearwater, FL.

Attended my second VMware User Group Meeting (VMUG) today. The first meeting that I attended was held at the Southwest Florida Water Management District’s office a couple of month back. Today’s meeting was sponsored by Tech Data and held at their Clearwater, FL headquarters.

First up was VMware which gave a presentation of upcoming features in View 4.5. Numerous alpha/beta screenshots were displayed which showcased numerous improvements and new features. We were asked as group not to share the exact features as this is still a work in progress so I will end that there.

Next up was IBM with a more hardware CAPEX/OPEX oriented presentation. Some of the hardware that was discussed was really impressive, things like 2TB of system RAM, blade enclosures, and 1.8″ SSD “flash packs” that cut costs and push IOPS through the roof.

The final presenter Qlogic, was pretty interesting. The presentation included 8Gb FC, fibre channel over ethernet, and 10Gb copper.

After the presentations everyone broke up into groups and went on tours of the Tech Data Solutions Center and then into discussions with each of the three presenters.

See you at the next VMUG.

–Himuraken

Recreate OWA Virtual Directory IIS7 / Exchange 2007

Ran into an issue today where a clients SBS 2008 server stopped servicing requests made to hostname/owa. I am still unsure as to what caused this issue but find a fairly simple way to recreate the OWA virtual directory for IIS. Many admins are familiar with this procedure / howto for Exchange 2003 but are unable to find something similar for Exchange 2007. While the step that I will describe below is not as in depth as the previous link, it did resolve my issue.

If your OWA is giving you the dreaded 404 treatment try this: Open IIS Manager and delete the OWA virtual directory. Next you will need to open the Exchange Management Shell. Enter in the following command and press enter afterwards: New-OWAVirtualDirectory -OwaVersion:Exchange2007 -Name "OWA" .

That will rebuild / recreate the OWA virtual directory and start accepting client requests immediately. Please note that this recreates the OWA virtual directory under Default Web Site, not under SBS Web Applications like a default SBS / Exchange 2K7 install.

Hopefully, this one liner will save you some trouble.

–Himuraken

The Beauty of Being Hardware Agnostic

We can all agree that virtualization has numerous benefits. One of the obvious benefits is that virtualization makes systems hardware agnostic. This is one of my favorite features of going virtual. I am responsible for the network operations of many businesses and being able to forget about hardware compatibilities on the OS level is a major advantage.

We experienced the benefits of this ourselves today while upgrading one of our servers. We added additional RAM and changed CPUs. The memory was no surprise, it is rarely an issue. When it is, it is a hardware issue not an OS one. CPU swaps are generally more complex. I have seen many Windows systems become unstable after increasing or decreasing the number of processors/cores.

So when we got the chance to upgrade one of our ESXi servers from two dual core processors over to two quad cores we had to test it. In true anticlimactic fashion everything worked perfectly. The VMware server booted flawlessly and now shows the additional cores and RAM.

So if you can get your hands on upgrade parts or new servers all together, go for it!

*Update* We have since bumped the server up to 32GB of RAM, great stuff. We plan to upgrade the CPU’s again in the near future. It just keeps getting better.

–Himuraken

Breath a little life into your Small Business Server

This one seems like an obvious one, but I will post it anyways. Chances are that you have deployed and/or maintain Windows 2003 Small Business Server. Many small businesses purchased SBS during “the good times” of 2003-2008.

Due to the licensing restrictions imposed on the product by Microsoft, these servers are always one boxed. That is to say that they have too many servers and services on the same hardware. Most of these systems are reaching their end of life and are running slower than ever.

These 32bit boxes are usually maxed on RAM (4GB) and are starving for more. Lately I have been auditing the list of installed applications and removing as needed. The memory hog is usually some SQL server running even though it isn’t in use. Take into account Backup Exec, WSUS, SBS Monitoring, and Sharepoint and you begin to see where all that RAM is going. Almost all of my clients have been moved over to a managed services platform which handles Windows Updates and system monitoring. That takes out two standard SQL databases/instances right off the bat.

So the long story short is this: Reevaluate the needs of your aging servers and get more from them by removing obsolete tools.

–Himuraken