Cisco’s Unified Computing System (UCS) was a bit of a blank-slate approach to computing, trying to answer the question of what a compute platform should look like in a post-virtualization world. Cisco’s approach unifies network and storage fabrics within an enclo-sure, reduces the number of points of management, and provides a policy and pool-based approach to server provisioning. It also allows you your choice of blade or rack-mount form-factors.
The smarts of UCS are housed in a pair of fabric interconnects, which run the UCS Man-ager software to control and manage the entire compute domain. Each fabric interconnect
56 CHAPTER 6 Converged Infrastructure
has upstream connections to external network and, optionally, SAN, and downstream
“server port” connections to fabric extenders, implemented as either IO modules housed in blade enclosures, or top-of-rack style Nexus 2000-series devices. Each fabric extender functions as a remote line card of the fabric interconnect. The fabric extenders are com-pletely dependent on the fabric interconnects; they cannot themselves forward traffic.
Traffic flows into a fabric interconnect via an Uplink Port, then down through a Server Port to a fabric extender, and ultimately to the blade server or rack-mount server.
To be clear, this is a rather unique offering in the converged space—typically, converged infrastructure limits the design to either blades or a “blade-like” enclosure and does not allow you to use a rack-mount server.
Why is this relevant? Not all workloads can fit in a blade form-factor. One example is Apache Hadoop—it is a big data analytic cluster that can benefit from having many slow, local hard drives to use the inside of each server, more than can fit into a single blade.
Figure 6.1 shows a UCS chassis, with its IO modules connected to a pair of fabric interconnects.
The fabric interconnects function as end-host devices —they act like switches on the server-facing side, but like server NICs on the network-server-facing side. This eliminates some of the caveats of traditional switches. An end-host device cannot form a loop, and as such, there is no spanning tree to concern yourself with. This means that every uplink from the fab-ric interconnect to the upstream switches can be active. Multiple connections from each IO module to its fabric interconnect can also be made without worrying about loops—
depending on your configuration, the links between each IO module and the fabric inter-connect are treated as a port-channel bundle, or blades are pinned to a particular uplink.
This ensures that traffic can flow up all uplinks. The fabric interconnects do not learn about any of the MAC addresses for entities not within their control. When switching traf-fic, any destination MAC address that is unknown is forwarded out an uplink port and is expected to be handled by a fully featured switch upstream.
All network configuration necessary for the servers is performed in UCS Manager. You define the VLANs, Quality of Service policies, MTU size, and number of NICs each server will have. Servers are usually configured to be stateless—a service profile contain-ing MAC address and World Wide Name (WWN) identity information pulled from pools, network, and SAN configuration, and boot from SAN or LAN configuration details is associated with the physical blade. This allows for quick and easy replacement in the event of a failure—you replace the failed blade and re-associate the service profile to the replacement.
58 CHAPTER 6 Converged Infrastructure
the architecture is designed to allow a wide variety of blade switches to be used, even from other vendors such as Cisco and Brocade.
In contrast to Cisco UCS, where a pair of fabric interconnects form a domain with all of the blade enclosures, BladeSystem puts a fair bit of control and management into each individual blade enclosure. In fact, each enclosure houses an Onboard Administrator (OA) and eight slots for various networking modules. This gives the administrator flexibility to custom tailor each enclosure to specific needs (such as the amount or use of Fiber Chan-nel, Ethernet, or a mix of both). The tradeoff for such flexibility is that each point needs to be managed and maintained as an individual entity, although management software does exist to allow combined control for the entities via offerings like HP Virtual Connect Enterprise and HP OneView. The contrasting point is that Cisco UCS has one point of logical management, while HP BladeSystem has many. We’re not prepared to say one is any better than the other; this is just a point you should be aware of when working with either system.
From a networking perspective, HP BladeSystem is focused on a technology called Virtual Connect (VC) . These are switching modules that work in a transparent mode, which is very similar to end-host mode with UCS. The VC modules are typically deployed in pairs that sit next to each other within the enclosure. You have the choice of configuring the mod-ules to be active and passive, where the passive module takes over if the active module fails, or running active and active and allowing the underlying vSphere hypervisor to shift traffic over to the active module in the case of failure. The decision to choose between active and passive versus active and active typically comes down to traffic flows and the north-bound switching architecture. HP has what they call a Cook Book to show you how to build both—we go into some details on blade server architecture beginning in Chapter 11, “Lab Scenario.”
HP BladeSytem gives you the ability to define VLANs, virtual NICs, NIC speeds, and so on from within the VC manager. Configuration is done once with a VC Domain (be that a single enclosure or multiple enclosures with VC Enterprise Manager) and can then be used repeatedly for each current and additional blade. You can also use VLANs that exist only within BladeSystem for local traffic, such as vMotion or Fault Tolerance, if that would be optimal for your architecture or design. Additional automation and self-service features are available when BladeSystem is deployed as part of an HP CloudSystem Matrix solution.
Figure 6.2 shows the business end of an HP BladeSystem c7000 enclosure.
Examples 59
Figure 6.2 HP BladeSystem rear view