Posted by Brian on Feb 2, 2012 in Cisco UCS | 0 comments
I recently took and passed the Cisco UCS Design Specialist exam 642-982. There was not a lot of information out there on this exam so I thought that I would write a short summary of my thoughts. To start off I was not sure what to expect out of the exam because there is very little information to tell you what you should study and there are no books targeted towards this exam.
I am not surprised by the lack of prep material since it’s a design based exam. In my opinion this is one of the exams that you just need the real world experience of working with the product over time to be confident that you have the knowledge to pass the test.
Of course I’m not going to spit out a bunch of questions that you should study. The test does present a bunch of different design scenarios that might cover things like environmental variables, security questions or technical requirements. You then must make your choice based upon the given parameters. The part that I was least happy with was how little content there was about actual UCS design decisions. Sure there were things like converged networking and cabling, but actual questions that required you to build a design were somewhat limited. The exam seemed to focus more on the overall Cisco data center methodology rather than just UCS as you would think.
Brian is a Technical Architect for a VMware partner and owner of this website. He is active in the VMware community and is helps lead the Chicago VMUG group. This blog Virtualize Tips was started to document and remember things that I come across while working with tech.
Mail | Web | Twitter | LinkedIn | More Posts (169)
Posted by Brian on Mar 21, 2011 in Cisco, Hardware | 3 comments
I was recently introduced to Cisco UCS and have been really enjoying working with the product. After working with HP, Dell and IBM products for almost 20 years it has been a refreshing change. Sure I was keeping an eye on what Cisco was doing with UCS and reading what others have been writing. But after working with the UCS and sitting for the UCS class I am a firm believer in what they have created now.
So I figured that it would be good just to write down a few of the little things that have impressed me so far. I will be writing a lot more about UCS in the coming weeks. But these are just some UCS features that I thought were cool.
This is no surprise but does the back of your server rack look this clean? Unless you have a UCS blade chassis I doubt it does. Sure other vendors have been creating Blade Chassis for years and they have done many things to cut down on cable clutter. But nothing comes close to making things this simple and clean.
The next one is maybe not so much a technology innovation but it’s just something so simple that I can’t believe no one has done this before. On each UCS blade server that is a little paper card that flips out. This can be used to write server names, put asset tags or other labeling details. No more are the days were you are forced to paste labels on the front of servers reducing the air flow by partially covering up some of the vents. This seems so dang easy but I’ve not seen any other vendor do this yet.
This will probably have people split on if its good or bad. Every UCS blade and C series rack mount server has the console port on the front and you can use the dongle in the picture below to access. The UCS dongle provides you with a video port, 2 USB ports and a 9 pin serial connection. This gives you the ability to connect monitor, keyboard and mouse to any blade or server. You could also use it for a console connection to a nearby switch if your laptop like many does not have a serial port. Sure others will probably say why would you want this when I just cable up my chassis to a KVM and forget about it. But after years of working with remote data centers and having a wide variety of skilled and non-skilled works there to be your hands in a crisis. This makes things dead simple just connect this dongle to server 1 and what do you see on the screen. No more try to remotely talk someone through how to use a KVM and never really being sure if they are looking at the right screen.
Brian is a Technical Architect for a VMware partner and owner of this website. He is active in the VMware community and is helps lead the Chicago VMUG group. This blog Virtualize Tips was started to document and remember things that I come across while working with tech.
Mail | Web | Twitter | LinkedIn | More Posts (169)
Posted by mike on Mar 5, 2011 in vSphere | 1 comment
ESXi behavior with NIC trunking
Sometimes very challenging problems will arise. Things that make you scratch your head, want to hurl your coffee cup, or just have a nice cold adult beverage. Customers can change a projects requirements mid-way through, a vendor’s storage array code upgrade can go awry, or a two can creep into the ones and zeros.
In this section, we present examples of those crazy situations with the hopes of helping out our fellow engineers in the field before they become as frustrated as we have!
Recently in working with a customer, the request was for a new cluster comprised of ESXi 4.1 hosts. They would be using just two onboard NICs for the vmkernel and virtual machine traffic. These two NICs would feed into a pair of Cisco Nexus 5020’s, using virtual port channel (VPC).
Because of the use of VPC, the virtual switch load balancing needs to be set to IP Hash for the NIC teaming policy. Okay, no sweat! After installing ESXi and completing the initial configuration on the hosts, it was time to add the second NIC to vSwitch0 and plug it in. (Note this configuration is all being done on the hosts directly as no vCenter server has been built yet). After adding the second adapter to the active section of vSwitch0, and changing the NIC teaming policy to IP hash, we plugged in the second cable.
The host immediately lost connection from our vSphere client, and dropped off entirely from being able to be contacted. No ping, no nothing! This was most puzzling indeed: we unplugged the second cable and the host started to ping again. We thought maybe there was something wrong with the NIC itself, and so setup a separate NIC to take its place. This had the same result, and we then thought to look at the switch. After discussing the current configuration with the network engineer, we felt that his configuration was correct. The configuration (and more!) can be found in the white paper put out by Cisco and VMware: “Deploying 10 Gigabit Ethernet on VMware vSphere 4.0 with Cisco Nexus 1000V and VMware vNetwork Standard and Distributed Switches – Version 1.0” This doc has been a very helpful during the implementation of this project.
So! With the network being deemed not the problem and wearing a sheepish smile on my face after the network guy commented “it’s always the network isn’t it?” I returned to the host. I then tried setting up both NICs on a non-nexus switch that is being used for out of band management, and they worked just fine using virtual port id for NIC teaming. So at that point, I fired up the googalizer and did some checking. I came across this KB article from VMware:
VMware KB 1022751: NIC teaming using EtherChannel leads to intermittent network connectivity in ESXi
Details:
When trying to team NICs using EtherChannel, the network connectivity is disrupted on an ESXi host. This issue occurs because NIC teaming properties do not propagate to the Management Network portgroup in ESXi.
When you configure the ESXi host for NIC teaming by setting the Load Balancing to Route based on IP hash, this configuration is not propagated to Management Network portgroup.
So, based on this very helpful information, I followed the instructions listed in the KB and had great success. Now my ESXi hosts are talking on both NICs via IP Hash and life is good.
read more
Posted by Brian on Jun 29, 2010 in Cisco, Hardware | 0 comments
Today Cisco announce a sweet looking Android based Tablet. The tablet will offer HD video streaming, real-time video, multi-party conferencing, plus all the regular tablet functions like messaging, email, and browsing. The expected release date should be some time in first quarter of 2011. Full press release listed below.
Brian is a Technical Architect for a VMware partner and owner of this website. He is active in the VMware community and is helps lead the Chicago VMUG group. This blog Virtualize Tips was started to document and remember things that I come across while working with tech.
Mail | Web | Twitter | LinkedIn | More Posts (169)
Posted by Brian on Mar 23, 2010 in VMware | 0 comments
I saw the announcement today that Cisco has announced the Nexus 1010 network management appliance. The idea behind this is to let the network team manage the Nexus 1000 like a physical switch would be. The Nexus 1010 can host up to 4 Nexus 1000v Virtual Supervisor Modules (VSM). The appliance will also server as a launching pad for future options like NAM or Firewall services. The device is set for availability in April/May of 2010 and it’s retail price is $24,995.
Cisco lists the following ways it would benefit different teams. The server team could benefit by offloading VSM management to the network team. The network team would benefit by installing the VSM like a standard Cisco switch and preparing for VM growth with support for up to 256 hosts per appliance.
Nexus 1010 Hardware configuration
2* Intel X5650- 2.66GHz, 6 core
4* 4 GB RDIMMs RAM
2* 500GB SATA-II HDD
1* Broadcom Quadport GbE 5709 NIC Card
Below you can see a comparison of the different management options between the hardware option or a virtual machine.
Brian is a Technical Architect for a VMware partner and owner of this website. He is active in the VMware community and is helps lead the Chicago VMUG group. This blog Virtualize Tips was started to document and remember things that I come across while working with tech.
Mail | Web | Twitter | LinkedIn | More Posts (169)
