Posted by Brian on Feb 3, 2012 in Cisco UCS | 0 comments
I recently had the opportunity to configure my first set of Cisco 6248 fabric interconnects for Cisco UCS. These are a bit different from the 6100 series FI’s that Cisco has been using since it’s release. The 6120 and 6140 fabric interconnects required an expansion module to be purchased and installed in the FI’s to achieve Fibre Channel (FC) connections. This made configuring pretty straight forward in the UCS Manager (UCSM). It was clear which ports were for FC and it just took a right click to configure them.
With the 6248 fabric interconnects they follow the path that the Nexus 5K series from Cisco have gone with all the ports being Unified Ports. Meaning they can do 1/10GigE or Fibre Channel. I like this direction because it offers more ports and greater flexibility for the FI’s and customers. But when it comes to configuring the FC uplink ports it’s not as clear as it was in the past. You would think that if you right clicked any of the ports you would be presented with an option to make the port an FC port but that’s not the case.
Below I am outlining the steps it takes to enable ports for FC uplink status.
Step 1: You will make sure you are on the equipment tab, then click on the first Fabric Interconnect. In the window to the right you will see the following options in the Actions area. You will need to click on the Configure Unified Ports option.
Step 2: You are going to see a window open that matches the one in Image 2 below. This shows a visual presentation of the ports in your fabric interconnect. The most important thing here is the somewhat obscure white slider bar that is just below the image. I have pointed an arrow to it. When you first arrive at this screen the slider will be all the way to the right, I have slide it 2 rows to the left. This will allow me to configure the last 4 ports as FC uplinks. You can adjust for what you require for your UCS design.
Image 2
Step 3: In image 3 below I have placed a box around the ports that I intend on changing to be FC Uplink ports to make sure it’s clear.
Image 3
Step 4: The last thing to do in this part of the config is to right click on each port and choose Configure as FC Uplink Port. This will allow you to connect to your switching fabric.
Image 4
Step 5: After doing this on the first FI it will tell you that it needs to reboot. Once the FI has rebooted you will need to do this same config change on the 2nd FI.
Step 6: Now when you look in the tree and find the section for FC Uplinks you will see the ports that we configured. Now make sure the proper VSAN is enabled for each port and you should be ready to proceed with the rest of your install.
I want to say thanks to my coworker “Mr UCS” Steve Pantol for the heads up on this saving me time trying to figure this out.
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 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 Nov 9, 2011 in Blade Servers, Cisco UCS, Hardware, HP | 0 comments
This is a conversation that gets asked a lot when discussing the platforms with customers. Can you explain to my why Cisco UCS is easier to manage and what tools do I need to use on a daily, weekly or monthly basis. The answer is really easy with Cisco UCS, you just need to use UCS manager. For HP the conversation becomes more splintered, sure you can do pretty much anything on HP blades that you can do on UCS. But how many tools or management points do you have to touch to accomplish these same things. Below I have attempted to list common tasks that you would need to do for setup and on going management of a blade enclosure and blades within.
Cisco UCS Manager – Does all the following in one tool
- Blade Chassis mgmt
- CIMC console connections
- Hardware Monitoring
- Firmware updates – chassis, FEX modules, blades and adapters
- QOS
- Network Mgmt
- Service profiles for blade identities
- SAN connection setup
Roll Based Access Controls – Can assign ID’s access to all or just allow server, network or SAN access
HP Blades – using Virtual Connect modules of any flavor
- Blade Chassis mgmt. – Onboard Administrators (OA)
- iLO console connections – OA
- Hardware Monitoring – HP SIM
- Firmware updates – HP SIM, FDT or currently used tool
- Network Mgmt – Virtual Connect Manager (VCM)
- Server profiles – Virtual Connect Manager (VCM)
- SAN connection setup – Virtual Connect Manager
- Roll Based Access Controls (RBAC) – need to configure logins per Tool
If you elected to use the new Cisco FEX modules for HP Blade chassis then the following would be affected.
- Network Mgmt / profiles – no profiles, would use physical address from Blades. Port configs done at 5K level. Blades auto map to ports on FEX similar to pass through connections.
- SAN connection setup – Would be done vid FCoE through the 5K switches
- Network QOS – Done on 5K switches and tagged if possible in Operating Systems (ESXi 5 does support 802.1p)
If you have anything that I left off of this list drop me a note in the comments and I will update to keep accurate.
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 Nov 8, 2011 in Blade Servers, Hardware, HP | 0 comments
I was talking with a fellow VMware nerd today about cloud and infrastructure gear. And I can’t help but wonder why it takes HP so long to execute on integrating their products, mostly around the support tools. Look HP owns a complete stack now, network, compute, storage and software. Along with their suites of tools that you need to use to manage all these devices independently. To me this is their biggest failure and does not appear to be getting fixed anytime soon.
This is a big bonus of working Cisco UCS because there is just one place that I need to go to configure, manage, patch a blade environment. With HP I might have to use the Onboard Administrators, Virtual Connect manager and HP SIM. This seems like such a no brainer that HP could have fixed years ago, because the HP Blade systems have been around for years.
So if HP wants to rule the market in the Cloud era they need to reduce their tools into less management points. I should be able to do everything in one console for compute and if they could roll in storage to this also would be a huge win. And if they are properly motivated they can. Now a unified tool for automation of hardware that could reach into VMware with API’s would be the next big win. I know they are working on some of this but last that I saw it still sounded like there would be too many moving pieces.
So HP I challenge you to solve this issue with your massive amount of Talent, code and other resources. You need to become innovate again and make products that people want to own and desire for other reasons than you have a large install base and are cheaper.
If you want some examples you can read my post about the comparison of what tools it takes to manage HP vs Cisco blades chassis here.
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 Nov 7, 2011 in Blade Servers, Hardware, HP | 0 comments
Since vSphere 4 came along VMware has been working with CIM (Computer Information Model) drivers to try and present up details about the underling hardware that vSphere is running on. Initially this was things like health of CPU, Memory and errors like a failed fan and such. But something that I always thought was missing is visibility into locally configured RAID volumes.
For example if you are running ESX(i) on a mirrored pair of local drives, if you are a shop that does not have very good hardware monitoring you might have no idea of the health of this mirror that vSphere is running on. So this becomes even more important with more shops experimenting with running certain workloads on local disk. With VMware and storage companies creating Virtual Storage Appliances that can run on these local disks and still provide the benefits of shared storage, this becomes a must to understand what is happening in your local disks environment.
With the latest batch of CIM drivers from HP they are now exposing some of these details. You can now see the drive configurations and status. The image below shows that a drive is rebuilding in the RAID config. This should be a feature that many HP shops will be happy to see. If you have noticed any other good features from this update leave a note in the comments for others.
a
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 Jun 9, 2011 in Cisco, Cisco UCS, Hardware | 1 comment
I was helping out a team member with setting up AD authentication on a UCS chassis in our internal lab. It looked to be a pretty easy task but turned out to be a dog fight. In the end it was easy but I found a few errors in the Cisco document that explains how to configure LDAP for Cisco UCS. I will point out the items that caused me grief.
In the end its now working as expected and is a great feature to put to use. With so many different pieces of equipment in your environments being able to have a unified log in is much better than trying to remember 20 different local ID’s.
You can download and view a copy of the LDAP for Cisco UCS guide from here or a Google search will turn up the same thing.
Error #1
In the “Creating LDAP Provider” section the main part that tripped me up was the following.
If you refer to the image below shows the highlighted portion according to the document. I have updated the instruction below. Once I changed this the authentication worked immediately. Before changing it would just fail and according to the logs on the AD server it was not even making the attempt and failing.
c) This should be the string for the Bind user that you created earlier in the document. Example below
BindDN value is CN=ucsbind,OU=CiscoUCS,DC=sampledesign,DC=com
Error #2
This section in the collecting information section was also wrong. It did not cause me any issues but did require me to go back and read things a few more times to make sure.
In part d it references OU=CiscoUsers in the string. But the instructions never requested us to create this OU. It should just be the OU=CiscoUCS that you did create. Nothing to cause you issue just to clear things up.
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)
