Friday, June 5, 2009

Blade Server Networking Basics pt. 1

Blade technology has permeated the datacenter ecosystem. I consider these chassis to be the IT generalist's "dream machines" since they combine a little bit of everything into one neat package. Actually, pairing a blade environment with virtualization should make any techhead salivate... but I digress.

Blades present some opportunity/need to apply a little more network savvy then the typical VLAN|port|plug and play server setup. The concepts and settings I will discuss below come from experience with IBM BladeCenter and HP BladeSystem configurations, but I'm sure they can be applied to offerings from Dell and the like.

The first difference right out of the gate is how the physical NICs of the blade are handled. Since there is no port on the server to plug into, connectivity must be handled through the chassis. The chassis provides hardwired connectivity from the blade slots in the front to the module bays in the back. These hardwired routes can be used to provide Ethernet and/or fiber channel connections to the outside world and between blades. For example, a blade in slot 1 will map out to blade port 1 maps to port 1 in module bay 1, blade port 2 maps to port 1 in module bay 2, etc. depending on how many bays the chassis provides. What is important to note is what type of devices are installed on which ports of your server blade. For instance, a common configuration of an IBM HS21 blade comes with 2 NIC ports and 2 HBA ports. These are installed as the first 4 ports of the blade with the 2 NICs first. When configuring the chassis you will want to make sure you install the appropriate modules in the appropriate bays to match up to this port layout. Also, make sure future blade purchases must match this configuration. *** Note: There are options available, such as HP VirtualConnect Switches, while provide for users defined mapping of ports to blades. These will not be discussed here.***

Two ways to connect the server to the outside world are via a pass-thru port or a switch module. Most vendors offer a pass-thru port option, which is basically a way to extend the hardwired connection from the blade slot to a standard RJ45 port. Personally, I have never used this type of connectivity and find the concept somewhat limiting (though there may be uses I have not thought of).

The switch module alternatives provides more flexibility and offer familiar configuration options from vendors like Cisco, Nortel and HP. There are many choices and capabilities out there but for the purposes of this post I'll stick with the Cisco 4-port GB Ethernet Switch Module. Switch modules of this ilk provide 4 external 10/100/1000Mb copper ports and 1 internal port for each blade slot. As mentioned above, the chassis bay the switch module is installed the into must match up with the NIC ports on the blade. If you do not see link on the blade ports, you've likely install the modules into the wrong bays. The management interface of the chassis should also report an error.

Continuing on with the physical setup, Figure 1 and 2 below show some options to connect the external ports to a redundant switch infrastructure. In these methods thru-put is maximized by aggregating the 4 ports per switch via etherchannel. The resulting portchannel is then configured for 802.1q trunking to pass the VLAN traffic configured for the blades (more on that later).

The configuration illustrated in Figure 1 shows an IBM BladeCenter H connected to a stacked pair of Cisco 3750G switches. A stacking cable is used in this instance but a portchannel between the switches can work as well. This setup uses a 1 to 1 HA pairing between the BC switches and the 3750s. If any one of the devices should fail all traffic will flow across the other path. The upside of this config is that its easy to trace and makes troubleshooting simpler. The downside is there may be a brief interruption to some servers as the path changes (this depends on how teaming is configured for the server NICs).

Figure 1

Figure 2 is similar to the previous example except that it splits switch module connections between the two 3750s. Note, this setup will only work with a stacking cable since it makes the 2 switches behave as a single unit. A single port channels cannot be configured to span across two separate switches. The advantage of this configuration is that the loss of 1 3750 will not impact on the downstream servers. Both blade switches will continue to function over their two remaining ports. The downside is a slightly more complicated implementation. It is important to document and label carefully in order to keep the port mappings straight.

Figure 2


This concludes part 1 of this discussion. Part 2 will cover how to configure the blade switches and servers to take advantage of the configurations illustrated above.

0 comments:

Post a Comment