Hardware

You are currently browsing articles tagged Hardware.

Don’t You Just Love It?

Sunday, February 6, 2011 in General by slowe | 8 comments

Recently…

Facilities: “We need to do some power load testing in the lab where your equipment is housed. You need to shut down your equipment.”

Me: “OK, no problem. I’ll shut down my equipment.”

So, I go to the lab and shut down all my equipment: eight servers, four Fibre Channel switches, two Nexus 5010 switches, a fabric extender, two older (pre-CX4) CLARiiON arrays, two VPLEX clusters, and two small AX arrays.

Me to Facilities: “OK, all the equipment is shut down; you’re ready to proceed with the power load testing.”

Facilities: “Oh, never mind. We decided not to do the testing.”

Don’t you just love it?

Tags: , ,

Netronome, 1 Year Later

Sunday, October 24, 2010 in Networking, Virtualization by slowe | 2 comments

In August 2009 I wrote about a company called Netronome and the network processor they were developing. Late last week I had another conversation with Netronome and was able to follow-up on last year’s discussion as well as get an idea of where they might be headed.

The product in question in August 2009 was the Network Flow Processor; specifically, the NFP-3200, a 40-core processor specifically designed to provide line-rate functionality like switching, load balancing, firewalling, or Quality of Service (QoS)—all embedded in hardware and handled directly by the NFP-3200. The idea, of course, is to offload all this functionality into the NFP so as to reduce the load on host CPUs. You can get a few more details about the NFP-32xx via Netronome’s product page.

At first glance, it might seem like Netronome hasn’t made a great deal of progress since last year. In August 2009, Netronome only had support for open source Xen. Unfortunately, that’s still the case today. However, Netronome’s business is a bit different. The comparison was made to Bose: you can buy a Bose radio as an OEM part from BMW, but you can also buy a Bose radio directly from Bose. In Netronome’s case, you can buy NFP functionality when it is embedded into another manufacturer’s products, or you can buy Netronome’s products directly. In the past year, Netronome has been primarily focusing on the former line of business (the OEM aspect). For example, Netronome’s NFP is used in an intrusion prevention system (IPS) produced by Sourcefire.

Based on my conversation late last week, it would now appear that Netronome is preparing to add a bit more visibility to their second line of business: selling Netronome-branded products. One of the form factors Netronome is exploring is a PCIe-based card with the NFP embedded on the card; this will be a dual-port 10GbE card that offers hardware-based, line-rate switching and QoS. VMware vSphere support is tentatively targeted for Q2/Q3 of 2011 (although, as with all roadmap dates, that might change). The idea here is that an IT end-user could install this card into their servers and gain hardware-virtualized NIC instances and hardware-based switching functionality directly on the card. In VMware environments, this means you could leverage something like VMDirectPath to bypass the hypervisor. Astute readers will, of course, immediately point out that VMDirectPath has its own challenges (like losing vMotion in its current incarnation); Netronome will need to address those challenges in order to make their product valuable to the end-user community.

Netronome’s dual-pronged business model—targeting both OEMs and end users—means that their measures of success are very different than what many readers would consider success. For Netronome to become a Tier 1 supplier of components to a major networking vendor or carrier would be a huge success, even if Netronome-branded products never take off. As for the end-user focused business, I’ll reiterate today what I said a year ago after first speaking with Netronome: the real challenge for Netronome is getting the appropriate support from major vendors, including VMware, and addressing some of the challenges of the potential use cases for their product.

In the spirit of full disclosure, Netronome did not provide any consideration or compensation for this blog post; I wrote it because the technology sounded interesting and I thought it was something about which my readers might be interested in learning more.

Tags: , ,

Some UCS Links

Wednesday, August 18, 2010 in Virtualization by slowe | 2 comments

Nothing too terribly new or innovative here; I just had some Cisco UCS-related links I wanted to share with everyone. I hope that you find something useful here.

Cisco UCS Server Pools: Use Cases
Placement of mezzanine adapters in full width blades
Chassis Discovery Policies in UCS
Cisco UCS Server Pools: Configuration
Why Cisco UCS is my ‘A-Game’ Server Architecture
Verifying FEX Uplink Pinning in Cisco UCS
Cisco UCS Pools In Depth
Myths and Restrictions of the Cisco UCS
Correction to L2 Forwarding Rules post
UCSM 1.3(1c) Released!
Cisco UCS Enhancements in Firmware 1.3
Cisco Unified Computing System: Power and Physical Requirements

Tags: , , ,

Some Vblock Posts

Wednesday, May 26, 2010 in Virtualization by slowe | No comments

The Vblock is starting to get a bit more attention, which is a good thing. Part of it is driven by an increased awareness of the Vblock as a solution; I’d like to think of that as something Ed Saipetch and I had a little to do with after our Gestalt IT Tech Field Day presentation in Boston, but I’m not so naive as to actually believe that. However, I am confident that part of the increased visibility and discussion around Vblock is due to the continued investment and continued persistence by all three members of the VCE Coalition. Regardless of the reason, I’ve collected a few Vblock posts here for your continued enjoyment:

The Case for the Vblock « Jason Nash’s Blog
Vblocks – StorageNerve
VCE VBlock – Perspective for the Technical Decision Maker
VCE Vblock – Alignment of Technology and Operations
UCS, VCE, Acadia, Vblocks and the Journey to the Cloud
What makes up a VCE Vblock 0? Overview Video with Scott Lowe & Mike Foley
Cisco, VMware, EMC Detail Ambitious Vblock Expansion

Tags: , , , , ,

Creating UCS Service Profiles Part 4: All Together Now

Tuesday, May 11, 2010 in Virtualization by slowe | No comments

This is the fourth and final post in my series on creating Cisco Unified Computing System (UCS) service profiles. What I’ve tried to do so far in this series is define the various elements that I recommend you create or define before you start trying to create a service profile or service profile template. Certainly you could start creating service profiles right off the bat, but I’ve found it easier to have all these other elements defined first. In part 1 of the series, I showed you what networking-related elements to define. In part 2 of the series, I described the storage-related elements, and in part 3 of the series I covered the remaining elements.

Creating a Service Profile Template

Now that all the prerequisite elements have been defined, follow these steps to create a service profile template (creating an actual service profile would follow the same basic steps):

  1. Right-click on Service Profile Templates and select Create Service Profile Template.
  2. On the first screen, supply a name for the new service profile template and make the template an Updating template. (This will ensure that changes made to the template are propagated to service profiles cloned from this template. You can always unbind the service profile from the template to prevent changes from propagating.)
  3. Select the UUID pool created earlier.
  4. Supply a description for the service profile template. Click Next to continue.
  5. On the second screen, select the desired local disk configuration policy.
  6. Do not select a scrub policy.
  7. Select Expert for the method of configuring SAN connectivity.
  8. Select the WWNN pool created earlier.
  9. Near the bottom of the screen (you might need to scroll down to see it), click Add (with the green plus symbol) to add a vHBA.
  10. Specify a name for the vHBA, such as “vHBA-A”. This name should match the name specified in the boot policy defined earlier.
  11. Select Use SAN Connectivity Template.
  12. Select the vHBA template created earlier and, optionally, an adapter performance profile. Click OK to return to the service profile template wizard.
  13. Repeat to add a second vHBA (if a dual fabric configuration). When using blades that have the Cisco Virtual Interface Controller (VIC) mezzanine card (aka “Palo”), the number of vHBAs can be greater than two.
  14. When you are done adding vHBAs, click Next to continue.
  15. On the third screen, do not select a dynamic vNIC connection policy.
  16. Select Expert for how you would like to configure LAN connectivity.
  17. Click Add (with the green plus symbol) to add a vNIC.
  18. Specify a name for the vNIC (like “vNIC-A”) and select Use LAN Connectivity Template. If you intend to use network boot, the name specified here must match the vNIC name specified in the boot policy.
  19. Select the vNIC template you created earlier and, optionally, select an adapter performance profile.
  20. Click OK to return to the service profile template wizard.
  21. Repeat steps 17 through 20 for each desired vNIC. When using blades that have the Cisco VIC mezzanine card the number of vNICs can be greater than two.
  22. When you are finished adding vNICs, click Next to continue.
  23. Do not make any changes to the vNIC/vHBA placement. Click Next to continue.
  24. Select the boot policy you created earlier. Be sure that the local disk configuration policy selected in step 5 is consistent with the boot policy you just selected. (This means that if the local disk configuration policy is set for No Local Disk, then your boot policy should not specify local disk as a boot method.)
  25. When prompted for server assignment, choose Assign Later and click Next.
  26. At the final screen, choose the IPMI profile you created earlier and the serial-over-LAN policy you created earlier.
  27. Click Finish to complete the creation of the service profile template.

And that’s it! What you should have found in walking through these steps is that the process of actually creating the service profile template was really just a matter of selecting pools and policies that you’d already defined. By doing all the legwork up front, you dramatically simplify the creation of the service profile or service profile template.

Of course, one of the advantages of UCS is its flexibility; meaning you don’t have to do things this way. This is just one way that I’ve found quite useful and, to be honest, a way that makes sense to me.

Courteous comments are always welcome! Feel free to add any clarifications, corrections, or other thoughts in the comments below.

Tags: , ,

Creating UCS Service Profiles Part 3: Other Elements

Monday, May 10, 2010 in Virtualization by slowe | 1 comment

This is part 3 of a series of posts on the various elements involved in creating UCS service profiles. In part 1, I discussed the networking-related elements. In part 2, I covered the storage-related elements. In this post, I’ll discuss all other elements. The next and final post will bring all the elements together and create a service profile or service profile template.

In addition to the networking and storage elements I’ve discussed thus far, there are four more elements left to define before you create your service profile or service profile template:

  1. At least one UUID suffix pool
  2. An IPMI profile
  3. A serial over LAN policy
  4. A boot policy

Instructions and more information on each of these items is found in the following sections.

Creating a UUID Suffix Pool

Location in UCSM: Servers tab – Servers > Pools > UUID Suffix Pools
Prerequisites: None

Here are the steps to create a UUID suffix pool:

  1. Right-click on UUID Suffix Pools and select Create UUID Suffix Pool.
  2. Supply a name and a description for the UUID suffix pool.
  3. Normally the Prefix should be set to Derived; this means that UCSM will automatically generate the prefix. If you want to specify the prefix manually, select Other.
  4. Click Next.
  5. You will now need to add one or more UUID blocks; by default, there are none in this pool. Click Add (with the green plus symbol) to add a UUID suffix pool.
  6. Specify a starting value and the size of the UUID suffix pool, then click OK.
  7. The UUID block you created is now listed in the UUID suffix pool. Repeat steps 5 and 6 to add additional blocks as needed. When you are done, click Finish.

Defining an IPMI Profile

Location in UCSM: Servers tab – Servers > Policies > root > IPMI Profiles
Prerequisites: None

To define an IPMI policy—which can be used by VMware DPM to control blade power state—follow these steps:

  1. Right-click on IPMI Profiles and select Create IPMI Profile.
  2. Specify a name and a description for this IPMI profile, then click the green plus symbol to add an IPMI profile user.
  3. Supply a username and password for the new IPMI profile user and select to make the new user an admin user.
  4. Click OK to add the IPMI profile user.
  5. Click OK to create the new IPMI profile.

Creating a Serial over LAN Policy

Location in UCSM: Servers tab – Servers > Policies > root > Serial over LAN Policies
Prerequisites: None

Here are the steps to create a serial over LAN policy:

  1. Right-click on Serial over LAN Policies and select Create Serial over LAN Policy.
  2. Specify a name and description for the serial over LAN policy, whether to enable or disable serial over LAN access, and the desired serial speed.
  3. Click OK to complete the creation of the serial over LAN policy.

Creating a Boot Policy

Location in UCSM: Servers tab – Servers > Policies > root > Boot Policies
Prerequisites: None

To define a boot policy, use these steps:

  1. Right-click on Boot Policies and select Create Boot Policy.
  2. Specify a name and description for this boot policy.
  3. Add boot devices from the list of potential devices on the left side of the window. For example, to add SAN boot, expand vHBAs and click on SAN boot.
  4. Specify the vHBA name and whether it should be primary or secondary. Make a note of the vHBA name specified here; it must match the vHBA name you specify later in the service profile template. Click OK to add the vHBA to the boot policy.
  5. Click Add SAN Boot Target.
  6. Specify the boot target LUN ID (generally should be zero) and the boot target WWPN, which would be the WWPN of a port on the storage array.
  7. Select whether this target should be primary or secondary, then click OK.
  8. Repeat this process to add LAN boot or local boot selections. If you add LAN boot, then (just as with SAN boot) be sure to make a note of the vNIC name you specify in the boot policy. You’ll need to make sure it matches information in the service profile or service profile template later.
  9. Click OK when you are finished specifying the boot devices and the order of the boot devices. (You can use Move Up and Move Down to change the desired order of the boot devices.)

That wraps up part 3 of the series. I’ve now covered all the different elements that I recommend creating before creating an actual service profile or service profile template. In the next and final post in the series, I’ll walk through creating a service profile and show you how easy it is once you’ve defined all these other objects.

Tags: , ,

Creating UCS Service Profiles Part 2: Storage Elements

Friday, May 7, 2010 in Storage, Virtualization by slowe | 1 comment

This article is part 2 of a series of posts that provide some additional inormation on creating UCS service profiles. In part 1 of the series, I discussed some of the networking-related elements that you should create before you create your service profile (or service profile template). In this post, I’m going to discuss the storage-related items that you should create in advance of creating the service profile (or service profile template).

Much like there are three networking-related elements you should define before defining the service profile, there are five storage-related elements that I recommend you define in advance of creating a service profile:

  1. At least one WWNN address pool
  2. At least one WWPN address pool
  3. All the VSANs that need to be visible/accessible within UCS
  4. At least one vHBA template
  5. A local disk configuration policy

Below I’ve included the steps for creating each of these elements, along with their location in UCSM and a brief mention of any prerequisites.

Creating a WWNN Address Pool

Location in UCSM: SAN tab – SAN > Pools > WWNN Pools
Prerequisites: None

Here are the steps for creating a WWNN pool:

  1. Right-click on WWNN Pools and select Create WWNN Pool.
  2. Supply a name and description for this WWNN pool, then click Next to continue.
  3. Click Add (with the green plus symbol) to create a new WWNN address block. (This is a brand new pool, so it starts out with no address blocks.)
  4. Specify the starting WWNN address. As with MAC addresses, these addresses are not shared or coordinated among multiple UCSM instances, so you should take steps to ensure that WWNN addresses are unique across the entire SAN fabric. For example, you could use the sixth hextext to denote UCSM instance (01 for the first UCSM, 02 for the second UCSM, etc.). Note that Cisco provides a base WWNN address that they strongly recommend you use in order to ensure unique addresses across the SAN fabric.
  5. Click OK to add the WWNN address block.
  6. Repeat steps 3 through 5 to add more WWNN address blocks as needed. Click Finish to create the WWNN pool.

Creating a WWPN Address Pool

Location in UCSM: SAN tab – SAN > Pools > WWPN Pools
Prerequisites: None

Here are the steps for creating a WWPN address pool:

  1. Right-click on WWPN Pools and select Create WWPN Pool.
  2. Specify a name and description for the new WWPN pool, then click Next.
  3. Click Add (with the green plus symbol) to add a new WWPN block.
  4. Specify the starting WWPN address. As with MAC addresses and WWNN addresses, these addresses need to be unique across multiple UCSM instances, so specify the base address accordingly. To ensure uniqueness, it is also possible to specify a different Cisco OUI (for example, to use 20:00:00:25:b4:xx:xx:xx as the base address instead of 20:00:00:25:b5:xx:xx:xx as the base address), but it is unclear what risk this raises of potential SAN address conflicts. This page provides a list of registered OUIs that you can use to help ensure unique addresses.
  5. Click OK to add the WWPN block.
  6. Repeat steps 3 through 5 to add more WWPN address blocks as needed. When you are done, click Finish to complete the creation of the WWPN pool.

Defining VSANs

Location in UCSM: SAN tab – SAN > SAN Cloud > VSANs
Prerequisites: None

Here are the steps to define a VSAN that must be visible/accessible in UCS:

  1. Right-click on VSANs and select Create VSAN.
  2. Specify a descriptive name for the VSAN.
  3. Select whether the VSAN should be global to both fabrics, specific to only a single fabric, or configured differently on each fabric. Generally, when defining VSANs, each VSAN is specific to a particular fabric. Select the appropriate fabric that will host this VSAN.
  4. Specify the VSAN ID and the matching FCoE VLAN ID. The FCoE VLAN must have been already defined, and fabrics cannot share the same FCoE VLAN.
  5. Click OK to create the VSAN.
  6. Repeat this process for all other VSANs that must be visible within this UCSM instance. If this is a dual fabric installation (and all production installations should be dual fabric installations), you will also need to repeat this process to define the VSANs for the second fabric.

Creating a vHBA Template

Location in UCSM: SAN tab – SAN > Policies > vHBA Templates
Prerequisites: WWNN pool, WWPN pool, VSANs

Here are the steps to create a vHBA template:

  1. Right-click vHBA Templates and select Create vHBA Template.
  2. Supply a name and description for the new vHBA template.
  3. Select the fabric to which this vHBA will connect.
  4. Select the VSAN to which this vHBA will be associated.
  5. Select Updating template so that changes to this vHBA template will propagate to vHBAs created from this template. In general, this is less of an issue with vHBAs than it is for vNICs.
  6. Select the previously created WWPN pool. Generally, all other values on this dialog box remain at their default values.
  7. Click OK to create the vHBA template.
  8. In a dual fabric installation, you must repeat this process to create a vHBA template for the other fabric. If you are using a Cisco Virtual Interface Controller (VIC) mezzanine card, you can define multiple vHBA templates per fabric.

Creating a Local Disk Configuration Policy

Location in UCSM: Servers tab – Servers > Policies > root > Local Disk Config Policies
Prerequisites: None

If you are using organizations (for role-based access control), you might need to define this policy within the specific organization where you want it to be visible. Otherwise, here are the steps for defining a local disk configuration policy:

  1. Right-click on Local Disk Config Policies and select Create Local Disk Configuration Policy.
  2. Specify a name and description for the new local disk configuration policy.
  3. From the drop-down list, select the configuration mode for this policy. When doing boot from SAN, select No Local Storage from the mode drop-down list and ensure that hard drives are not actually installed in blades to which this policy will be applied. This policy won’t apply successfully (when incorporated into a service profile) if hard drives are installed in the server. Likewise, selecting a mode that requires hard drives to be installed will fail to apply to blades that don’t actually have hard drives installed. You will want to verify that the local disk configuration policy you define will actually apply to the blades that are found within the UCS.
  4. When you are ready, click OK to create the local disk configuration policy.

In part 3 of the series, I will cover any other remaining elements that I recommend you define in advance of creating your service profiles or service profile templates. Then, in part 4, I’ll bring it all together and discuss the creation of a service profile or service profile template when you have pre-created the elements I’ve described in this series.

As always, feel free to post questions, clarifications, or corrections in the comments below.

Tags: , , , ,

Creating UCS Service Profiles Part 1: Networking Elements

Wednesday, May 5, 2010 in Networking, Virtualization by slowe | 2 comments

This article is part 1 of a series of posts that provide some additional information on creating UCS service profiles. In this part of the series, I provide some guidelines on networking-related elements that should be created before you create a UCS service profile. By creating these elements before creating the service profiles or service profile template, the process of creating the service profile or service profile template is a bit smoother.

There are three key networking elements that I recommend defining before you create a UCS service profile:

  1. At least one MAC address pool
  2. All the VLANs that need to be visible/accessible within UCS
  3. At least one vNIC template

The steps for creating each of these elements, along with their location in UCSM, is found below.

Creating a MAC Address Pool

Location in UCSM: LAN tab – LAN > Pools > MAC Pools
Prerequisites: None

Here are the steps for creating a MAC address pool:

  1. Right-click on MAC Pools and select Create MAC Pool.
  2. Specify a name and description for the new MAC pool, then click Next.
  3. Click Add (with the green plus symbol) to add a new MAC block.
  4. Specify the first MAC address and the size of the MAC block. Keep in mind that MAC pools (and the MAC address blocks within them) are not shared across UCSM instances, so be sure to provide a way of distinguishing MAC addresses across multiple UCSM instances. For example, use the fourth hextet to denote a UCSM instance (01 for the first UCSM instance, 02 for the second, etc.). This will help generate unique MAC addresses across multiple UCSM instances.
  5. Click OK to add the MAC address block to the MAC pool.
  6. Repeat steps 3 through 5, as needed, to add more MAC address blocks to this MAC pool. When the MAC address pool is complete, click Finish to complete the creation of the new MAC pool.

Defining VLANs

Location in UCSM: LAN tab – LAN > LAN Cloud > VLANs
Prerequisites: None

  1. Right-click on VLANs and select Create VLAN(s).
  2. Specify a descriptive name for the VLAN.
  3. Specify whether the VLAN should be global to both UCS fabrics, specific to only one fabric or the other, or if the fabrics should be configured differently for the same VLAN. Generally, VLANs will be configured as Common/Global.
  4. Specify the VLAN ID(s) that are associated with this VLAN object in UCSM. Generally, each VLAN object in UCSM should only have a single VLAN ID associated with it. If you enter multiple VLAN IDs (like “70-75″ or “21-24,27″), UCSM will create separate VLAN objects for each VLAN ID specified. This makes the creation of multiple VLANs a single step.
  5. When the dialog box is complete, click OK to create the VLAN object.
  6. Repeat this process to create VLAN objects for all VLANs that should be available within this UCSM instance. Use multiple VLAN IDs, as outlined earlier, to streamline the creation of multiple VLANs at the same time.

Creating a vNIC Template

Location in UCSM: LAN tab – LAN > Policies > vNIC Templates
Prerequisites: MAC address pool, VLANs

  1. Right-click on vNIC Templates and select Create vNIC Template.
  2. Specify a name and a description for this vNIC template.
  3. Select the UCS fabric to which this vNIC template should be associated. Do not select Enable Failover when using VMware ESX/ESXi. Note that you will need to create vNIC templates for both fabrics in dual fabric configurations.
  4. Leave all targets selected.
  5. Select Updating to make this an updating template. As additional VLANs are added in the future, modifying this template will then automatically modify service profiles created from this template to make the new VLANs available to associated blades.
  6. Place a check mark next to each VLAN that should be visible to vNICs created from this vNIC template.
  7. Mark one of the selected VLANs as the native VLAN; traffic from this VLAN will be untagged traffic. (In VMware ESX/ESXi, this traffic would require a port group with a blank VLAN ID configured.)
  8. Select the MAC address pool created earlier.
  9. If necessary, choose values for QoS policy, network control policy, pin group, and stats threshold policy. In general, these values do not need to be set.
  10. When the dialog box is complete, click OK to create the vNIC template.
  11. If this is a dual fabric installation, repeat this process for the second UCS fabric.

In part 2 of the series, I’ll provide information on the storage-related elements that I recommend creating before you create a UCS service profile.

If you have any questions or clarifications, please feel free to post them in the comments.

Tags: , , , ,

Another Collection of UCS Posts

Monday, April 19, 2010 in Virtualization by slowe | 1 comment

It’s been a couple of months since I posted my last collection of UCS-related posts. Since that time, I’ve collected a few more posts, so here’s another collection of UCS posts (in no particular order).

The State of Statelessness: Cisco UCS vs. HP Virtual Connect
Gestalt IT Tech Field Day – On Cisco and UCS
How Cisco UCS Deals with Split Brains
L2 Forwarding Rules in UCS EHV Mode
Scalability Study for Deploying VMware View on Cisco UCS and EMC Symmetrix V-Max Systems
Cisco C200M1 CIMC Update Process

As I uncover more UCS posts, I’ll bring them to your attention here. If you have some useful UCS information or useful UCS posts, please feel free to add them to the comments below (with full vendor disclosure, please). Thanks!

Tags: , ,

A Collection of UCS Posts

Thursday, February 18, 2010 in Virtualization by slowe | 2 comments

There’s been quite a few good Cisco UCS posts published recently; I thought it might be handy to collect a list of some of them (I’m sure that I will miss some). Here are a few that I’ve seen over the past few weeks (in no particular order):

Swapping UCS Blades with Local Boot Policies
Get Spidey Powers with UCS; but with Great Power comes Great Responsibility
25 ways that Cisco UCS frees you to do other things
Cisco UCS – How Many FEX Uplinks Do I Need?
UCS local disk policy + some vBlock
Cisco UCS: different workload, different configuration, same blade. Simple.
Cisco UCS Information for “Server People”
Cisco UCS vs. IBM and HP – Where are the Brains?
UCS Gotchas? and how much time does it take day to day?

Anyone else have any UCS posts that have surfaced recently? Add them in the comments below.

Tags: , ,

« Older entries