HP Blades to Converged Networking with Cisco Nexus

Although Cisco UCS is the fastest growing Blade platform in the world, you can’t ignore the current market dominance of the HP C7000. So a very popular question the team and I get asked regularly, is how should I connect my C7000 to a Cisco Nexus converged network.

So we have a lot of options for this, but also a lot of issues as well.

From a HP point of view Virtual Connect is always going to be the way to go, and will have no doubt already been configured into the C7000 by default. There is now of course a big push by HP to look at the HP 5820 switch series with advanced Flex-Chassis for the network, but being realistic it is more likely to be connecting to an existing Cisco network, so the customer is always interested in the Nexus range of switches.

So how should we connect our Virtual Connect (FlexFabric) to our Nexus 5548UP?

FCoE will pop into the conversation and really should be the answer, however the HP FCoE protocol doesn’t currently support multi-hop FCoE so needs to be retained within the Chassis as the link from the Blade to the Virtual Connect and no further.

So we need some 10GB uplinks for our LAN and some 4GB/8GB FC uplinks for our Block base SAN connectivity.

Fortunately the Nexus switch is designed to facilitate both of these communication methods.

For LAN connectivity we can take advantage of the Virtual Port Channel capabilities of the Nexus range, using Cross-connected links to each Virtual Connect. A virtual PortChannel (vPC) allows links that are physically connected to two different Cisco Nexus™ 5500 Series devices to appear as a single PortChannel to a third device. The only question with this design is how many Uplinks to use and how to configure my NIC’s within the Virtual Connect technology. I could use all 8x uplink ports on my FlexFabric 10Gb/24-port module for LAN connectivity, but generally I want to keep two ports for Fibre Channel. This leaves me 2-6 Uplinks, but in reality 2x 10GBe Uplinks should be enough for even the most densely populated Chassis configuration (40GB in total). Downstream to my blade I can configure up to 4x NIC’s on my on-board LOM for connectivity to the FlexFabric, but as I want 1 to be a HBA we’re left with just 3x NIC’s per FlexFabric. I can now allocate different ports speeds to each NIC, which basically allows me to dissect the 10GB of bandwidth across these 3 interfaces.
See the Virtual Connect FlexFabric Cookbook for further design options.

Now the SAN connectivity. As I mentioned above, we have 2x uplinks available for the SAN and 1x HBA from each FlexFabric. These can run at either 4GB or 8GB native Fibre Channel. Of course we want to stick to the standard dual Fabric, Storage Area Network design, so don’t confuse this with the LAN VPC design and cabling! Each FlexFabric should be defined as a single side of the SAN and connected only to a Single Nexus 5500, although the dual links should be used for Link redundancy.

It is important to mention at this stage however that currently there is compatibility between the Virtual Connect range of switches and Nexus 5000 Series when running at 8GB for FC. The only fix currently is to clock the FlexFabric uplinks down to 4GB FC. HP and Cisco are aware of the problem and further information can be found under BUG ID CSCtx52991 at Cisco Bug Toolkit.

Here is a useful example of the connectivity for the FlexFabric through to Nexus, although it is worth highlighting that at present the FlexFabric doesn’t support a SAN port-channel across it’s uplinks to the Nexus, so the only port-channels will be vPC’s to the LAN.

So no 8GB FC, no SAN port-channels and no multi-hop FCoE…. this isn’t sounding too great!

Well what’s the alternative?
There are a few Architectural differences that we could look at through Xsigo and of course Cisco UCS, but for the simplest change that still gives us the connectivity we require then the way to go has got to be the Cisco/HP B22HP Fabric Extender!

What’s so good about the B22HP you may ask, well the answer is simple. It delivers everything and more from a connectivity point of view, as well as simplified network configuration. As with other Nexus Fabric Extenders, it is seen as a remote Line card from the parent Nexus switch, and is able to provide the full capabilities on the Nexus switch directly to the HP blade. The B22HP provides truly converged networking extending 10GB FCoE up to the Nexus parent switch, and if required multi-hop FCoE all the way to the Storage Array.

The B22HP can be configured in a single homed or dual homed design benefiting from the Nexus vPC technology and providing flexibility in deployments, please see the design guide for further details.

Although the B22HP doesn’t currently provide the Dynamic Multi-NIC configuration of the Virtual Connect, it will provide Enterprise Class QoS delivered right to the blade. So intelligent use of QoS to the host can allow for consistent, reliable and high performance networking throughout the infrastructure.

For increased flexibility the B22HP is available in two flavours, the default SFP+ version allows for the use of standard 10GB SFP transceivers including Twinax (up to 10Meters) to reduce costs. As well as the FET bundle version that includes 16x SFP+ Fabric Extender Transceivers (8 for each end) specifically design to reduce the cost of Fibre-Optic connectivity for the Nexus range of switches.

With Cisco continually developing the Nexus range and the growth of support for VM-FEX and Adapter-FEX technologies the B22HP is really looking like the right path to take your C7000 chassis into the future of converged infrastructure.

…… well at least until you move to Cisco UCS!

WHAT, WHY, HOW……Nexus 1000v

Although the Nexus1000v has been with us for a couple of years now it’s still a bit of a mystery as to what it is, why it was create and how it works or gets deployed. So I thought I’d take the time to give you all my explanation and thoughts about the product.

So WHAT is it?

The Nexus 1000v is a virtual switch, meaning it is able to provide Network communication like a switch but run as at the virtual machine level and is completely independent of a hardware device, so a switch without a switch! It works in conjunction with VMware vSphere 4.0 (upwards) and has already been ratified to work with Hyper-V 3.0 when it launches. So for anyone who is familiar with VMware, they should know that in order to provide switching for Virtual Machines each vSphere host will run a local vSwitch within its hypervisor in order to distribute traffic from multiple VMs out through the shared Network cards. The Nexus 1000v forms part of Cisco’s Data Center class Nexus series of switches and runs the NX-OS operating system.

But WHY did Cisco make it?

Well IT departments can be a little “Siloed” with different teams of people responsible for different areas of the infrastructure. The Networking team manage the Network, the Server team manage the Servers and the VMware team manage the virtual environment….simple yes?

Unfortunately not….. and I know from experience. When a new Blade chassis arrives at a customer site the Server team or a Server engineer will start the installation, when he gets to the switches in the back of the Chassis he asks the Network Engineer to help with the configuration, the network engineer simply states “I’m a networking guy, we don’t configure the Chassis switches, that’s your job”. So the Server guy clicks his way through the options until he’s happy that some communication is working. He then passes the new Chassis over to the VMware engineer who installs ESXi and starts setting up the basic config, when he gets to the local vSwitch configuration, he then asks the networking engineer to help with the configuration and I’m sure you can guess the response (and  I am one of the few people who can get away with saying this, as many of you will know me as a Server guy, and VMware guy and a Network guy). So what were left with is three sections of switching all configured and managed by three separate teams we limited visibility as to the whole environment. Cisco have never been too happy about this, mainly because as soon as someone has a performance issue with their application, computer or Server the first thing to be blamed is the Network and as it’s split up into all these different section, then it’s very hard to state categorically that it’s not the network without a few days investigation, by which time the issue has magically disappeared and normal service is resumed.

So Cisco and the Networking team want to take back control of all areas of switching and have the visibility of all traffic on their network to reduce the chances of misconfiguration and simplify troubleshooting. At the same time VMware were aware that the major network vendors weren’t happy with the functionality of their vSwitch, so created an open API for their DVS and invited all the vendors to see if they could do better. Cisco were first to respond to the invite with the Nexus 1000v and I have to say they have done a pretty good job with it.

So HOW does it work?

Well first off you need to make sure you can deploy it. The Nexus 1000v utilises the VMware Distributed Switch technology to function and as such requires you to have VMware Enterprise Plus licensing. The Nexus 1000v can then be purchased in line with the CPU model VMware use. It can be a little expensive if purchase on its own, but Cisco do offer it for free if purchase alongside Cisco UCS. I think because of this, people seem to think the 1000v can only be used with UCS, but this isn’t the case. The 1000v only requires vSphere (or Hyper-V 3.0) and can be deployed on any hardware platform. It is made up of two parts, the Virtual Supervisor Module (VSM) and the Virtual Ethernet Module (VEM). The VSM is the control plane for the 1000v and integrates with multiple VEM’s which are embedded into each vSphere host. The VSM runs as a Virtual Machine and can be deployed via an OVA template, the VSM can be made redundant across a pair of VSM virtual machine configured as a cluster. The VSM also benefits from features such as HA and vMotion within the virtual environment. Once the OVA is deployed, the configuration and management of the 1000v is all done via the Command line (CLI), which is how networking people like to interact with things. The CLI commands are NX-OS based and simple to use. The setup wizard allows for the pairing with a vCenter Server, which then presents itself as a DVS within vCenter. The Network team are then able to create each of the port-groups required by the virtual environment and apply standard networking polices right down to the virtual machine level. The two key factors for this are Netflow and QoS, meaning that you can take the existing Quality of Service settings running in the rest of the network and even apply them to the traffic between two VMs on the same host!

Once the Configuration is done and all the Port-groups are available in vCenter, the VMware team (while working with the network team this time) can begin to migrate the Hosts and VM’s over to the 1000v. When a Host is added to the 1000v, update manager is used to deploy the VEM component into the hypervisor. The VEM itself handles all the switching independently of the VSM, although all configuration is referenced through the VSM. When new Port-Groups are created at the VSM level, the VEM in each connected host is updated. Once the Port-Groups are created they become available for the VMware team to select them from the drop down list of Port-Groups when configuring a Network Card for the VM.

So in conclusion the Nexus 1000v passes control of the network back to the network team and provides a variety of enhancements over the traditional vSwitch.

The product can be a little tricky to install and falls in a grey area between Virtualisation and Networking.

There is a lot of development by Cisco and other vendors in this area at the moment and I aim to follow this article up with more about the Virtual Security Gateway VSG and VM-FEX as an alternative way to control Virtual Machine networking.

For anyone who’s interested in testing the Nexus 1000v out, it is available for a free 60 Day trial and can be downloaded from either Cisco or VMware’s websites.

There are some considerations and best practices for Nexus 1000v, and below are my thoughts that may be of interest to the more technical people reading this.

Considerations:

COPY RUN START!

The Nexus 1000v is a switch and needs to be treated as one. Anyone deploying this for the first time, will see that as you enable a new Port-Profile, the relevant Port-Group is created in the vCenter immediately. However just because it’s written to vCenter doesn’t mean it’s written to the Nexus 1000v. Always remember to Copy the running configuration to the start-up configuration whenever you make a change or create a new Port-Profile.

SYSTEM VLANs

When setting up the “Ethernet” Port-Profile for the Uplink ports, you are requested to specify the “System VLANs”. The instruction for the deployment will tell you to make sure that the Packet, Control and Data vLANs for the Nexus 1000v should be set to System vLANs. However the purpose of a system vLAN is not always explained. A System vLAN is a vLAN that is able to become active when an host server first powers on and activates the VEM, without the VEM first communicating with the VSM. So whatever vLAN the VSM sits on must be a System vLAN, but at the same time whatever vLAN the vCenter server is on must also be set as a System vLAN, otherwise communication to the vCenter server may not be established! Also if your using NFS or iSCSI to access datastores it’s a must to make these vLANs System vLANs as well.

It is also essential that a System vLAN is configured for any "vethernet" Port-Profile that is used by one of these vmKernel ports or the Nexus 1000v and vCenter Virtual machines. 

BACKDOOR

Always think about an alternative method for accessing the local ESXi console in case you make a mistake during the installation of the Nexus 1000v and the migration of the hosts and VMkernel ports. UCS will provide KVM Console access directly to the host, but other vendor hardware may need an ILO or DRAC to be enabled first.

HOW MANY NICs

It used to be that VMware required around 6 to 8 NICs to provide all the different types of communication and when Nexus 1000v was first launched this design was the recommended way to go. Recently however things have changed and with 10GB capabilities and several review of QoS designs the new “Best Practice” from Cisco for the Nexus 1000v is to utilise only 2x 10GB NICs and have the Nexus 1000v manage all traffic across all port-groups. In the case of Cisco UCS, it is recommended that the two NIC’s created in the Service Profile are NOT enabled for Hardware failover as the convergence of the Nexus 1000v will be quicker and more stable.

DON’T RUSH!

So you’re ready to migrate your Hosts and VM’s over to the Nexus 1000v and the wizard in vCenter will let you do every single host and VM all at once, which is pretty cool……but don’t ever do that!!! The worst thing that can happen when migrating hosts and VM’s is to lose communication mid-way through. So in order to mitigate against this you should follow these steps:

1       Disable HA and DRS on the cluster before migration

2     Start with a single host and not the one hosting vCenter or the VSM

3     Move one of the two NICs first along with the VMkernel Ports for Management

4       Test communication with each VMkernel Port

5       Move a single test VM to the Nexus 1000v

6       Test Communication

7       Move the second NIC in the first host and any other VM’s on the host (then test)

8       Do steps 3 and 4 to a second host

9      Test vMotion between the first two hosts

10   Move the second NIC in the second host along with it’s VM’s

11   Once your happy everything is working on these two hosts, you can now move the rest of the Hosts, VMkernel ports and Virtual Machines.

12   Leave vCenter till last.

And hopefully that covers everything!

Nostalgia

Space Invaders

Combat

Frogger

Ms Pacman

River Raid 2

Circus Atari

1942

Paperboy

Gauntlet 2

Ghouls and Ghosts

Chuckie Egg

Lazy Jones

Daily Thompson Decathlon

Populous

Super Hang On

Rainbow islands

Double Dragon

R-Type 2

Bombjack

Xenon

Afterburner

Treasure Island Dizzy

Speedball 2

Commando

Oids

Tower of Babel

Kick Off 2

Lemmings

Worms

Micro Machines

Golden Eye

Tetris (on Gameboy)

Command and Conquer

And of course

Climbing trees

Curby

Rin Tin Tin

Conkers

British bull dog

London Street

...............I miss you all!

Small Kitchen Appliances

After over a month without an oven I finally decided to treat myself to a new Tefal Activfry, while simultaneously satisfying my craving for Sweet potato fries! After using it for 3 days in a row for a variety of meals and being very satisfied with the results, I started to consider the other essential small kitchen appliances I am dependant on.

Realising that I spent a considerable amount of time researching each appliance before purchasing them, I thought it would be helpful to friends, families and complete strangers to share with you my findings and my overall contentment with each item.

So here is a list of my top five must have small kitchen appliances:

Number 5:     George Foreman Family Grill

My particular model is a 6 portion family edition, and where I would highly recommended getting any grill in the extension range, I have to say the bigger the better! The grill is incredible versatile with quick and easy cooking for any meat that takes your fancy. The product line is designed to be healthy and convenient. It has a sloped grill design to channel the fat and run off away cleanly into a drip tray. The only downside is that is can be a little annoying to clean and occasionally gets overcrowded when trying to do a full English breakfast following a heavy night!

Number 4:    Nescafe Dolce Gusto Melody

I’ve never really been into Coffee, but when visiting a Starbucks I always felt like I was missing out. In order to try and embrace the fancy coffee culture I decided to invest in this Dolce Gusto and have never looked back. This convenient appliance is easy to use and can create a wide range of drinks including Latte Macchiato’s and my personal favourite the Café Mocha. All I need now is a machine that makes a Starbuck Grande Mocha Frappuccino and I’m laughing!

Number 3:     Russell Hobbs Quick-2-Boil Kettle

So we’ve talked about the fancy occasional coffee, but more importantly we need our regular cup of Tetley tea. Previously I had a Tefal Quick Cup deluxe to deliver almost instant boiling hot water, however when this broke I was very disappointed to discuss the product was discontinued by Tefal (possibly due to them exploding maybe). So a new search was begun to find the quickest way to make a single cup up tea. During the search I came across the Quick-2-Boil kettle and was instantly intrigued. Although not as quick as the Quick Cup Deluxe the kettle does have the ability to make a single cup of tea in less than 45 seconds, but has the additional benefit of a fully functioning kettle in the same appliance. Water in the kettle can be used for either purpose and even when boiling a full kettle you still only have to wait around 2 minutes. The only downside is that the amount of water dispersed by the single cup function cannot be adjusted to fit your particular cup size, although it does seem to be the exact amount of water need for my Bisto gravy on a Sunday lunch!

Number 2:     Morphy Richards Intellisteam

Now this was clearly the number one small appliance before my latest acquisition. I have been steaming vegetables for several years now and due to almost daily use most traditional steamers have just not been up to the job, generally breaking and needing to be replaced every couple of years. If you have never used a steamer for your vegetables then you are clearly missing out, as the natural flavour of the vegetable cannot compare if cooked by any other method. A traditional steamer uses a single heating element with tiered cooking trays in a tower. This means that everything has to be steamed for the same length of time with the top tier not cooking as well as the bottom one. You also get dripping from the top tier down through the others, so never put the sprouts on top! With the Intellisteam you have a far more sophisticate cooking system. It has three heating elements which effect the different cooking department combined with the ability to set varying cooking times for each section. The appliance will simply start steaming each section when required in order to complete each one at the same time ready for serving. The only small downside to the appliance is that it is pretty bulky and doesn’t easily fit in my sink or on my kitchen drainer.

Number 1:     Tefal Activfry

Now this appliance really is a revolution. Until now I have always considered Frying food, especially the deep fat frying of Chips as being not only unhealthy but also messy and a little dangerous. Now Tefal have  worked hard at this and created a frying system that combines several elements of cooking into a single device. There is a traditional heating system for the pan, but also a secondary heating system that warms the whole pan. There is also a rotary mechanism that gently stirs the food to help it cook more evenly. The result is an incredibly versatile system that is more like stir-frying than deep fat frying. It will cook a variety of foods including meats, vegetables and fish, without forgetting its primary purpose to make the best chips you’ve ever tasted. The ActivFry comes with a small cook book to advise you how to prepare food, which included details of how to make the prefect Sweet Potato fries. So far I can’t find a single thing wrong with the appliance and look forward to enjoying its creations for many years!