25 ways that Cisco UCS frees you to do other things

10. February 2010 · Write a comment · Categories: Operations, UCS

Let something else do all the work

If you’re a server admin, think how many times and how long each of the following 25 activities takes you and your team.  You infrastructure might be 10, 100, 1,000 or 10,000 servers.

They say the way to get a job done most efficiently is to give it to a lazy person.  When I was at Loudcloud our ethos was “Smart and lazy” and we automated as much as we could.  In the same spirit, the UCS wants to do things for you.

The Wire Once Walk Away design of UCS is all about codifying mundane practices and also expert decisions so operations can reuse them in a very efficient manner.  When you interact with the system, by adding servers or deploying workloads, the system takes care of many tasks for you.  Here’s 25 of those tasks which are handled by policies:

  1. Chassis Discovery – how many links should I use from the FEX (2104) to the FI (6100)?  This affects the path from blades to FI and the oversubscription rate.  If you’ve cabled 4 I can just use 2 if you want, or even 1.
  2. Power Policy – how many PSUs should I use, keep for standby and turn off?  This affects power consumption and ability to handle elastic workloads.
  3. MAC Aging – how shall I manage my MAC table?  This affects ability to scale, as bigger MAC tables need more management.
  4. Autoconfig - when you insert a blade, depending on its hardware config I shall apply a specific template for you and put it in a organization automatically.
  5. Inheritence - when you insert a blade, I’ll automatically create a logical version (Service Profile) by coping the UUID, MAC, WWNs etc.
  6. Server Discovery – when you insert a blade shall I automatically process it, or give you a chance to acknowledge it first?
  7. Server Events – how shall I manage these for you?  Want me to clear them, back them up, etc.
  8. Stat Thresholds – what do you want me to alert on?  Any object, any stat, any KPI, min/max/normal/delta?
  9. Stat Collection – how often shall I collect and report?
  10. vHBA Templates – what do you want _every_ vmhba2 to look like?  Fabric? VSAN? QoS? Pin to a border port?
  11. Dynamic vNICs – how do you want to distribute the VIFs on a VIC?
  12. Flow Control – how do you want to handle congestion?  PFC? On Rx? On Tx?
  13. Network Control – need CDP?  How should I report a link failure?  Shall I allow MAC forgeries?
  14. vNIC Templates – what do you want _every_ vmnic1 to look like?  Fabric? VLAN – native? trunk? QoS?  Network Control? Pin to a border port or port
    channel?
  15. Adapter - how shall I tune the blade CNA adapter for vSphere?  Queues? Offload?
  16. Boot - how shall I boot the blade? CD? Local? Network? SAN?
  17. Host Firmware – what firmware shall I apply to the CNA, the HBA, HBA ROM, BIOS, LSI?
  18. IPMI - how shall I configure blade management?
  19. Local Disk – any local disk?  RAID0? RAID1?
  20. Management Firmware – what firmware shall I apply to the BMC?
  21. Scrub - shall I wipe the local disks on association?
  22. Serial over LAN – shall I configure SSH access to the blade console for vSphere, RedHat etc.?
  23. Server Pool – what pools of blades can I choose from?
  24. Server Pool Qualification – what hardware configurations decide which pool I live in?
  25. vNIC/vHBA Placement - how should I distribute VIFs over one/two CNAs?

Lastly, the Call Home feature will even contact Cisco TAC for you when something goes wrong and raise a case for you.  How cool is that?

« Older articles
Newer articles »