Archive

Posts Tagged ‘logistics’

DataCenter Prep Complete for Cisco UCS

We completed our data center preparations a few weeks ago.    I knew we were getting some higher end power distribution units (PDUs) for the server cabinets, but I did not realize how big these items are.   We went with APC7866 PDUs for the following reasons:

  1. Two of them provide the requisite number of outlets that we need for an entire rack of UCS.
  2. The PDUs can be monitored via SNMP.  This cabinet is going to very dense in terms of compute power so we’ll need to stay on top of environmental and power conditions.
  3. Our Cisco SE recommended it.  Nothing like having equipment recommended by your vendors.

Below is a photo of the power outlet from out data center PDU:

As you can see, that goes from my colleague’s wrist to his elbow.   Now here’s a photo of the two PDUs (data center and server cabinet) connected:

The length of the two connectors is almost as long as a grown man’s arm!    Just for grins, here is what the server cabinet PDU plug looks like:

Those are some beefy looking prongs.  They need to be since we are looking at 3phase, 240volt, 60amp.

What are you using for your UCS implementation?

.

Advertisements

Update on Cisco UCS Training

June 14, 2010 1 comment

Oops..meant to push this out last week.  Sorry for being late.

——————————————-

I spent some time this morning talking with a representative from the training company about the UCS class that I took.   All-in-all, it was a positive discussion.  He explained to me the way vendor training works in terms of developing content, including what flexibility and restrictions are imposed upon the training providers.    Here’s what I came away with:

First off, the provider owned up to having wasted time in the labs via having us install operating systems.  They are going to look into the possibility of having the various operating systems pre-installed so that the labs go quicker/smoother.  It’s a 1.0 class so some kinks still have to be worked out.  Fair enough.

We also talked a fair bit about the connectivity problems.  I do agree with the provider that some of the issues may have been due to the wireless network of the hosting facility.  However, the instructor did tell us that the remote VPN had to be rebooted at least once for some of the problems to go away.     I am not sure how that would be the problem of the hosting facility’s network.  Either way, that is why I don’t like remote classes.   They add complexity to an already complex environment.

I should point out that the reason the class is delivered remotely is due to equipment costs.  I can understand that since a UCS setup can cost quite a bit.  The cost savings strength of  UCS occurs with growth (around 4 chassis), not initial acquisition.

I would like to clarify one item around connectivity.  Once the VPN issues were squared away, the lab equipment and labs worked.  Again, it was the VPN and related network items, that got in the way….on a daily basis…not the lab equipment and its setup.

My biggest gripe was with content.  The provider explained to me that Cisco provides the basic content package and that the training providers are given their flexibility in the labs.   I don’t know if this is 100% true or if I am caught in the middle of a he-said/she-said type debate.  Either way, I tend to believe the training provider on this.  I’ve taken many Microsoft classes over the years and they all are pretty much the same.  The only way that could be is if there was an overlord of some sort dictating content.    The flexibility in content comes from the discussion that should ensue after a topic is covered.  There wasn’t a whole lot of this going on and that was probably due to the newness of the product and the lack of product experience on part of the instructor.   It will probably be another year before instructors have enough hands-on experience with UCS in order to facilitate those extra discussions.  As for me, when something is new it is difficult to know which questions to ask so the war-stories that the instructor and fellow classmates bring are instrumental in my learning experience.

Content currency was another topic we discussed.  The provider mentioned that it is difficult to get content updated in a timely manner due to the requirement of receiving vendor approval.     Ouch.   Cisco UCS is a product that changes quarterly.  These new features have to make it into the curriculum somehow.

My last major point, briefly written about, was the lack of content regarding troubleshooting.  Regardless of who is responsible for developing the class, topics on troubleshooting are a requirement.  No ifs, ands, or buts.

So to summarize.  I’ll stick with my original premise that the class was a good overview, but not an in-depth technical class.  Given time, it will probably evolve into one though.   I’ll also stick to my premise that remote classes can be problematic.  I do want to give kudos to the training provider for contacting me and getting some direct feedback and taking action.  A quality organization thrives on customer feedback.

One final note:  I made a comment about the class being substandard.  In my opinion, the class was not up to my expectations and both the vendor and the provider own this one.    If Cisco is going to dictate content, then they better be responsive in keeping it current and in-depth.  The training provider is the one with the reputation on the line when people aren’t happy so it is in their best interest to keep the vendor on their toes.   When either one misses a beat, then everyone (vendor, provider, and customer) loses.

Customers should speak up more so that vendors and training providers can be more responsive in adjusting curriculum as products update/change.  If a class is not to your expectations, let the provider know.  Don’t just blithely fill out those feedback forms.  Be honest on them.  By doing so, everyone wins.

Categories: cisco, UCS Tags: , ,

Prepping for our Cisco UCS Implementation

The purchase order has finally been sent in.  This means our implementation is really going to happen.  We’ve been told there is a three week lead time to get the product, but Cisco is looking to reduce it to two weeks.  A lot has to happen before the first package arrives.  Two logistical items of note are:

  • Stockroom prep
  • Datacenter prep

What do I mean by “Stockroom prep?”  A lot actually.  While not a large UCS implementation by many standards, we are purchasing a fair amount of equipment.  We’ve contacted Cisco for various pieces of logistical information such as box dimensions and the  number of boxes we can expect to receive.   Once it gets here, we have to store it.

Our stockroom is maybe 30×40 and houses all our non-deployed IT equipment.  It also houses all our physical layer products (think cabling) too.    A quick look at the area dedicated to servers reveals parts for servers going back almost ten years.  Yes, I have running servers that are nearly ten years old <sigh>.    Throw in generic equipment such as KVM, rackmount monitors, rackmount keyboards, etc and it adds up.   Our plan is to review our existing inventory of deployed equipment and their service histories.  We’ll then bump up that info with our stockroom inventory to see what can be sent to disposal.   Since we don’t have a lot of room, we’ll be really cutting down to the bone which introduces an element of risk.  If we plan correctly, we’ll have a minimum number of parts in our stockroom to get us through our migration.  If we are wrong and something fails, I guess we’ll be buying some really old parts off eBay…

As for prepping the data-center, it’s a bit less labor but a lot more complex.  Our data-center PDUs are almost full so we’ll be doing some re-wiring.  As a side note, the rack PDU recommended by our Cisco SE has an interesting connector to say the least.  These puppies run about $250 each.  The PDUs run over $1200 each.   Since we’ll be running two 42U racks of equipment, that equals four of each component.  That’s almost $6K in power equipment!!

As another data-center prep task, we will need to do some server shuffling.  Servers in rack A will need to move to a different rack.  No biggie, but it takes some effort to pre-cable, schedule the downtime, and then execute the move.

All-in-all, a fair amount of work to do in a short time-frame.