Extreme therapy

I’m giving a presentation to a VCE global partner later today and I’m going to start it with an anecdote from my times in the trench to remind people of just one, personal reason why Vblocks are a good idea.  I think it’s worth sharing beyond these private meetings, if only for my own therapeutic reasons!

About three years ago I was part of a team to build one of the very first Vblocks in the UK.  This was right at the start of VCE’s genesis, while I was at Cisco.  There was no mature manufacturing facility back in those early days, and staff was very light compared to now.  We had design guidance from the other Vblocks that had been deployed, a reference architecture if you will, but it was a long way from today’s VCE capability.

I’ve been herding cats most of my life and this project wasn’t any different: the virtual team was created (VCE had one employee in Europe, and he was a sales guy) from Cisco, EMC, VMware, a large IT service provider and the customer teams themselves.  Let’s round it at twenty people, from different companies, in different parts of the UK, with different skillsets.

At the board level of the customer a commitment had been made to have the new, business critical service live before the end of the year.  The date was currently spring, so we had about six months to get it delivered, integrated and fully operational.

Long meetings were held of trying to get different people to communicate: it wasn’t that people were hostile, the team spirit was excellent, it was that there are three basic problems with getting different IT people to work together (even when they like each other, so imagine if they don’t!):

1. They speak a different spoken language, for example using different acronyms.  If people don’t understand, they stop listening.
2. They have a different unspoken language, in that they make assumptions of what others know because “it’s obvious” (to them).  This means stuff gets missed.
3. They have different priorities, because surely the network is the core of everything and everyone knows the cloud is about storage, right?  This means stuff gets missed.

So imagine trying to agree on a full-stack design guide (application down to power sockets).  This is before any real work has started!  (SHOCK: Drawing a Visio and writing a PDF is not real work.  You heard it here first.)  This is a design that makes simple assertions as to what the solution will consist of, in terms of components, how they are assembled and configured.  It also dictates integration points and brushes the cheek of operations, but daren’t a kiss.

Once you’ve stumbled, bloodied and battered out of the design sessions with a PDF in your hand, you now need to work out how to actually build it!  Have the experts configured a Nexus 5020 in this way before?  Have they cut a VMAX binfile for this configuration before?  Have they integrated a 6140 with a Cat6509 before?

The problem with being all shouty, either as a vendor or consumer, about using the latest, shiniest technology is…. very few people have done it in anger before.  You are likely to be the first to do this in production.  There aren’t lots of “best” or “proven” practices except those that were done in lab conditions (probably with different configurations and firmware to your scenario).  There aren’t loads of forum entries you can google for “Error 5230″. So what happens is you learn on the job.  You build it live, test it, then document it afterwards.  Remember we have a deadline here.

What’s more, if you are building this new, shiny tech with a newly formed virtual team on the customer site in their datacenter, you are most likely limited as to who can access the infrastructure in their datacenter, which means you have to be really good at team work because those twenty folks that have their own domain knowledge have to cram it into the heads of the few that are approved to enter the datacenter to do the actual build.  Yes, we are now in the olympic relay passing PDFs instead of batons.

Let me give you a personal account of why this occasionally fails badly: I worked on the northbound network connectivity and the Nexus 1000V virtual network, with help from domain experts in Cisco.  Design looked great.  Nice visio, using lots of colours and cool fonts, tacked on were obsessive-compulsive level build instructions: what could possibly go wrong?  Enter the relay!

We handed the instructions to the one approved guy who could go and do the work, a man who hadn’t been involved in any of the discussions so far, and he went and did his cabling job (under change control of course) and reported back a day or so later:

Me:  Create the Nexus 1000V VSM, ok.  Add the VEM to a host, OK.  Move the first NIC from the standard vSwitch to the VSM, ok.  Move the second NIC from the standard vSwitch to the VSM…. the host then disappeared from the VSM.  What on earth is happening?  Check all the configs.  Cisco Discovery Protocol (CDP) came to the rescue and we learned that the northbound cabling was wrong.  We called the guy up.

Me: “How did you cable the northbound connections?”

Him: “I just connected the fabrics to the switches.”

<I’ve cut out a lot of useless to-ing and fro-ing here, which felt like hammering nails into my skull (see pic)>

Me: “Did you follow the network diagram and the build guide?”

Him: “What diagram and build guide?”

Yes, the switches were misconfigured and miscabled.  I take part of the blame for not stapling the guide to the guys forehead.  Next time I will be smarter… It all had to be done again, following the guide this time.  We lost about a week doing this (don’t forget change control!).  How do you explain to a senior executive that his business app will be late because someone didn’t put the right SFPs together?

The moral of the story is this: building converged infrastructure is hard because of people not because of complex technology, even when you appear to have all of the knights of the realm sat at your table.  If it’s a new team, if it’s new tech, and you’re doing it on a customer site, please take off those rose tinted classes and your superhero underpants: they won’t help you.

That’s why I jumped at the chance to join VCE: I couldn’t go through that again, so now all the hard work is done in a manufacturing facility.  It’s shipped WORKING, and then you can give ops a full kiss on the lips instead of a brush on the cheek and get on with the real work of consuming your converged infrastructure, instead of fussing about patching leaks.

You. Have. Been. Warned.

Related posts:

1. Accept failure and build resilience and recovery into the system

After watching a bit of to-fro action between two of my geek heroes – @qthrul and @roidude – on the unwritten rules of social media, I thought of this graphic…

ViewYonder Tweet/Blog Tragic Quadrant

Related posts:

1. The ViewYonder ITIL Tragic Quadrant

Jeramiah has done a great job of explaining what VSPEX is and it’s relationship to other converged infrastructure approaches, even Mr Mellor at ElReg is wading in, so I’m going for the simple approach:

• VSPEX is more flexible than any other reference architecture such as Flexpod.
• VSPEX is a reference architecture so while it has the flexibility and the stacks of atoms might look similar, the deployment, support, maintenance, development and go to market is different to a product like Vblock.

And here’s a pretty picture:

But because this is the internet, we can (mis)quote Einstein!

Where VSPEX sits

Related posts:

1. What if a VCE Vblock Platform turned the VDI iceberg into ice cubes?

A script kiddie has eyes for reference architectures

This is Kevin. He’s a Script Kiddie.  We really need to talk about Kevin.

He’s a glass-half-full kinda guy!  He loves learning on the job, and he’s looking insanely happy because he’s been told he can build his first converged infrastructure by plagiarising someone else’s to-do list, also known as a Reference Architecture.

That’s right: as if his blindly plagiarising a simple best practice doesn’t cause enough damage, imagine him using a huge complex interwoven collection of them that stretches over one-hundred pages: that’s what a Reference Architecture is.

Chad Sakac has just posted an excellent blog on this topic, and it’s timely that I share eleven reasons why you should avoid the incorrect use of Reference Architectures, Dear Reader.

1. Best is a relative term.  Better than what?  If there are three ways to skin a cat, what is the best practice?  Well, if the guy that wrote it had a knife to skin that cat but you only have your teeth: what do you do now?  Before you buy a knife, check your name isn’t Reg Prescott.
2. Sharing is not caring.  Just because someone shares their practices with you (and I’m a fan of that, after all I did VIOPS), if you blindly copy what they did and it doesn’t work then do not expect them to help you.  You are on your own.  It’s all your risk.
3. Prepare to shave a yak.  When it doesn’t work (and believe me, it won’t) then will you know why?  Chances are this is your first time (otherwise why are you following a strangers to-do list?), and therefore you will get a sore head with all that scratching trying to figure out the answers.  I hope you can reach Google from the datacenter?
4. You will stray from the path.  You will have to customise the best practices in a reference architecture: but do you know what has to change due to different requirements?  And when you DO change something, what’s the impact of THAT change?  At this point you are on your own, your solution is not standard nor recognisable to the original reference.
5. Entropy is Flexibility’s evil twin.  The more you stray from the path the more you disintegrate the architecture and start to experience entropy: cause and effect start bouncing off each other like rabbits, breeding misconfigurations across your solution.  Think of “re-pristining” Windows OS: that’s Entropy in action on a small scale affecting one user.
6. The future is unpredictable.  Products change over time, so do people, so do solutions: everything changes: a reference architecture does not protect your from these changes.  Imagine you’ve got a converged infrastructure, that you’ve customised, and one of the elements has a new release: how do you do it?  Should you do it?  What happens if you do?  You. Are. On. Your. Own.
7. Come on in the water’s lovely.  Reference architectures are mostly marketing papers, giving you the illusion of a safety blanket so that you feel empowered to buy the latest widget.  That means you are at the cutting edge, installing version 1.0.  Is that blanket still keeping you warm?
8. Failure has many faces. Gone are the days when IT guys just had to keep the lights on.  Now they are being asked to do custom work at the speed of cloud providers.  Failure is now an East-West (solution lifecycle) as well as North-South (technology stack functions) problem.
9. Consumers have no tolerance for failure.  Clouds work indoors and outdoors today, and they are ready for your customers who have applications that need to work NOW while you’re creating a customer solution from someone else’s to-do list: if you fail (see point then don’t expect them to wait six months for you to get it right.
10. A fool with a tool is still a fool.  Think you can short cut the process and fix the above with a tool?  I see that Cloupia have an automated way of implementing a reference architecture for FlexPod, and HP have a million different incompatible products that need services… Think that’s awesome?  It certainly is: I can’t think of a faster way to implement all nine failure scenarios above.  Now you have to maintain the reference architect AND the tool AND integrate it… headache inducing.
11. IT people are horrible tech writers.  There are very few people I know in the tech industry who love also to write documentation.  And if you hate a job you are usually bad at it.  Bad means missing stuff, having sloppy commands that don’t work, and not keeping the document up to date.

All those 11 reasons multiplied together with various helpings of impact and probability give you a big old lump of risk that might be too hard to swallow.

There are two ways to derisk these eleven reasons though, and both of these are about the appropriate use of Reference Architectures:

1. A reference architecture has a single use-case: for learning about technologies and solutions.
2. For real life, skip the reference architecture and go to a reputable, experienced, knowledgeable, customer-focused partner to get it right.

Reference Architectures when used properly are great learning tools.  Take the Cisco Validated Designs (CVD) as a great example.  When I was at Cisco you would find a brilliant Technical Marketing Engineer to author a new CVD to combine new and exciting products together for the first time.  EMC and VMware do similar great work to showcase their technologies.  Yes it is possible to use OTV and VPLEX for long distance vMotion, but would you build this for real just using the reference architecture?

If someone claims to be a knowledgeable expert but then refers to a reference architecture, they aren’t likely to be what they claim.  A reputable expert will have superceded a reference architecture long ago and have their own kitbag from which to help craft a solution.  Great channel partners of the major vendors stand out immediately, if you need help finding one let me know!

If you want to create something as powerful as converged infrastructure to be right first time, be fit for purpose to run mission critical workloads and run for a significant period of business: don’t use a reference architecture!

No related posts.

Dear Clouderti,

I have of late, but wherefore I know not,
lost all my mirth, forgone all custome of exercise;

and indeed, it goes so heavenly with my disposition;
that this goodly frame the Cloud, seemes to me a sterile promontory;
this most excellent Canopy the Cloud, look you:

this brave ore-hanging, this Magesticall Roof,
fretted with golden fire: why, it appeares no other thing
to me, then a foule and pestilent congregation of vapours.

What a piece of work is a Cloud?
How noble in Reason?
How infinite in faculties, in form and moving?
How express and admirable; In action how like an Angel!

In apprehension how like a god, the beauty of the
world, the paragon of animals. and yet to me, what is
this quintessence of dust?

Public Cloud delights not me; no,
nor Private Cloud neither; though by your smiling you seeme
to say so

—The Tragedy of Hamlet, Prince of Denmark (Act II, Scene ii, 285-300), [1]
- inspired by Withnail and I, movie

No related posts.

Quick post to share a little Ruby script that lets you send commands and get output from the Nexus 1000V VSM.

HTML: Basic Ruby interface to the Nexus 1000V

Public Clone URL: git://gist.github.com/1326436.git

Enjoy!

class NX1K
require 'net/ssh'

attr_writer :host, :user, :pwd

def send(xml)
  session = Net::SSH.start(@host, @user, :password => @pwd, :timeout => 10, :verbose => :debug) do |session|
    channel = session.open_channel do |channel|
      channel.subsystem("xmlagent") do |xmlagent, success|
        xmlagent.on_data do |xmlagent, data|
          puts "(xmlagent) ON_DATA: #{data.inspect}"
          xmlagent.close if data === "]]>]]>"
        end
        xmlagent.on_close do |xmlagent|
          puts "(xmlagent) ON_CLOSE"
        end
        xmlagent.on_eof do |xmlagent|
          puts "(xmlagent) ON_EOF"
        end
        xmlagent.send_data(IO.read('nx1k_hello.xml'))
        xmlagent.send_data(xml)
      end #xmlagent
    end #channel
  end #session
end #send

end #class

vsm = NX1K.new
vsm.host = '192.168.1.130'
vsm.user = 'admin'
vsm.pwd = 'VCEr0cks!'
vsm.send(IO.read('nx1k_show_int.xml'))

Related posts:

1. Easy access to the Cisco UCS API via the Ruby UCSAPI Module
2. VMware + Ubuntu + Ruby + REST + XML + Cisco UCS API

Say Cheers to Vblock

It’s nearly a year since I first published the VDI iceberg and 20-layer model: time for an update.

The original idea behind the iceberg/20-layer model was to inject some humour into a difficult subject, being: VDI is hard, really hard.  There are so many moving parts that it’s not IF but WHEN and WHAT problems you will have with your project.  The size and complexity of the problem seemed to fit an iceberg…

Above the surface is all the End User Computing stuff – the users, the apps, the OSs.

Under the surface is all the unglamorous stuff that is either too hard or too boring or too complex or Somebody Else’s Problem, but most likely all four.  There are multiple worlds colliding (end users, desktop admins, network guys, ITIL thingies, storage, server, virtualization, engineering, operations…).

What if some of that pain could melt away if you buy a Vblock for VDI?  What if the VDI End User Computing experts could rely on the underlying platform to such an extent they could focus on what they are really good at – ie. virtual desktops, the apps in them, and how to manage the Desktop as a Service (perhaps!)?

Here’s the updated iceberg, and I think you’ll agree it’s much less daunting to an EUC/VDI expert.  If you disagree, click here for the original!

VDI Iceberg with a Vblock

 

So if you bought a Vblock to run VDI, did your iceberg just became a few ice cubes?

1. one slightly submerged for managing the apps as desktop as a service, and
2. another one for the end user computing stuff (end points, user virtualization etc).
3. a solid foundation, called a Vblock, to run VDI in the datacenter that was application aware and made it easy to bolt on VDI technologies like firewalls, load balancers and accelerators?

Still want to roll your own backend infra for VDI?  Anyone who thinks that’s a one-time engineering effort is sadly mistaken, but not alone, but I’ll indulge that and STILL we see that VDI projects are sensitive to Time and Visibility…

• The VDI projects I’ve worked on all had a common thread in their business case: a compelling event that drove the VDI adoption.  Whether it was an office closure, or relocation, or new office without enough power: they all had short time limits:
  IT Exec “We aint got all the time nor all the money in the world to do this”.
  
• Under such pressure, with such visibility on end user computing, do you have time, say six-to-twelve months to evaluate, test, design, blueprint, procure, engineer, build, test again, go live, migrate, load up, support and operate a custom built infrastructure back end?
  IT Exec: “VDI is the biggest career limiting decision an IT exec can make”?

Now here’s a crazy thought:  what if VCE isn’t (just) about Vblocks.  What if a Vblock is not the end, but a means to the end?  What if VCE cares about Vblocks only because they let people and organizations focus on the consumption of IT, not the provisioning?  

In case you’re in any doubt, let me leave you with a statement of fact: Infrastructure only costs money, it doesn’t make it.

You know and I know that the business only benefits when those applications are up and running and performing within the SLA, hopefully protected from the entropy that will ensue when the “solution” is thrown over the wall from engineering to operations.

That three month evaluation period to compare This Array to That Array, the five hundred engineering hours spent comparing PowerPath to native ESX path sharing: Really?  Are these people serious?

Well?  Am I Right?  Am I Wrong?  Comments please  And whilst you’re noodling on it, why not read this from my personal sponsor, VCE

Check out VDI FastPath from VCE is the next evolution of converged infrastructure from putting Compute+Network+Storage in one configurable container that has known qualities (very helpful in the fight against IT Entropy – more on that later), to now making those containers application optimized.

Now your iceberg is really a new solid foundation to run VDI on top of, because with FastPath Vblock you get:

1. a converged infrastructure product, not a PDF/CVD/DIG document
2. modular growth
3. simplified scaling
4. trusted multi-tenancy
5. deployment anywhere in the world through VCE and partners
6. seamless support
7. rapid provisioning/decommissioning of desktops
8. resilient architecture due to engineering and QA

Related posts:

1. Microsoft Enterprise Application Iceberg
2. VDI iceberg and 20-layer model
3. (VSPEX > FlexPod) != Vblock

This applies to all enterprise apps that need to run on highly-available, service-level-driven, on-premise infrastructure.

A picture paints a thousand words, but I’ll chuck in a few words just to make sure we’re all clear:

• Business demands focus on applications, how to generate revenue, how to increase margin, cut costs
• That drives focus away from “under the water” (ie. in the data center) infrastructure
• It also drives a focus on cheapest tin wins, which is like using spray-on cheese in a good restaurant.  Customers won’t come back.  If you have to ask why, you’re an idiot.
• If you think “under the water” is easy, you will hit the ice berg and be eaten by penguins.
• What you need is a way to do the “under the water” stuff in a repeatable, predictable, scalable, cost-effective way (VCE and Vblocks)

I’m picking Microsoft only because I’m presenting tomorrow at Microsoft, but all other vendor Enterprise Apps apply.

Now for the picture:

Enterprise Application Iceberg

Related posts:

1. Microsoft hearts Cisco UCS
2. VDI iceberg and 20-layer model
3. What if a VCE Vblock Platform turned the VDI iceberg into ice cubes?

I like it when it's stormy

Ever been on a British beach in winter?

Did you lean toward the on-shore gale, arms out-stretched as in a crucifix, with the wind whipping your hair and your eyes moistening with sea spray?  Ears hurting with the noise, the pressure, the cold?  Isn’t it FUN?!  I love it!

I’m nearing the end of my first quarter at VCE and has it been like body surfing in a storm.  I’m running a team of vArchitects in Europe that focus on service providers, and it is awesome.  I’m lucky to work with great people, there’s even a few ex-Loudclouders in here!  What are we doing at VCE?

Before VCE came along with their Vblock product, it was really hard, slow and expensive to deploy converged infrastructure: I know, because I’ve done several big ones and many small ones in my life at VMware and Cisco prior to VCE.  Why is it different at VCE?

Sit down with me and we can create a bill of materials from your requirements in less than 15 minutes.  If you press the Buy Now button then thirty days later it will be shipped to your datacenter loading bay on one or more pallets instead of hundreds of little boxes.

Then a VCE guy turns up in a taxi and in one day will have the whole thing running for you.  The day after that you can do your testing and launch your services and start making money.  Time to value and time to cash after making these kind of investments is what keeps the senior managers awake at night.

What goes on top of a Vblock though?  If you want a solution, VCE will take the lead and bring together some powerful functionalities and product sets so you don’t have to.  Watch this space for Trusted Multitenancy (TMT) including the market leading products from VMware, RSA, EMC, Cisco.  We just built this for a customer, from scratch, with no kit, to a fully functioning trusted multitennant Infrastructure-as-a-Service including VMmark2 (!) in less than four weeks.

And that, my friends, is why I work with Service Providers at VCE because you know what, it’s not really about a Vblock (we’ve solved that bit, let’s all move on now).  It’s about how you integrate it and run solutions on it to increase your margins and adopt new lines of revenue.  To quote one of my esteemed colleagues: It’s not about the hardware, it’s about the software.  We can only say that, though, because we have hundreds of engineers working thousands of hours to solve the hardware problem.  If you don’t do Vblock, you still have the hardware challenges to overcome.  Bon chance, mon ami.

What would the business prefer?  To be earning revenue from your new infrastructure in sixty days, or be still sitting in a room looking at a whiteboard and still doing the low level design and still working out which product firmware is compatible?  Been there, done that, now it’s up there with ITIL for me.  It is of value only to the professional services teams that charge customers for it.  It’s boring.  It’s dead, dead, dead.

I’ve been saying it since 2004 but I’ll say it again:  it’s not about provisioning, it’s about consumption.  If you spend 80% of your time talking about which SFP+ goes from here to there, then you are dead in the water.  VCE has done all that so you don’t have to.  We let you turn lots of knobs to get the performance and capacity you need, such as different RAID groups, but other than that we’d like to talk about something more interesting.

Like… how are you going to make money out of this thing?  And guess what?  VCE has some ideas to help you with that too.

I’ll be sharing these thoughts, such as In, With and On a Vblock, and topics like TMT and Service Creation over the coming weeks and months.

No related posts.

Quick note to remind you and highlight the key new features of the awesome 1.4 release.  Congrats to Cisco’s engineering team for getting this out!

The features this software release unlocks, and they are all awesome!

Update:  the docs are released, the code is on its way… I’ll update this post and my twitter feed when it’s all live!  It’s important the docs are released first so get reading and by the time you’re done, the code will be available

New Software Features in Release 1.4(1)

This release adds support for:

•Chassis and multi-chassis power capping for UCS B-Series < METER YOUR POWER DISTRIBUTION ACROSS 20 CHASSIS FROM ONE SCREEN!

–Power capping has been extended to cover chassis and groups of chassis and includes a policy based workflow using service profiles for setting it up.

•Software packaging with server bundles < FIRMWARE MANAGEMENT JUST STEPPED UP A GEAR, AWESOME!

–Support for server and adapter hardware can now be delivered independent of support for the infrastructure components. This allows customers to add support for new server types without having to upgrade their Fabric Interconnect or UCS Manager software.

Scalability

–UCS instances now scale to up to 20 UCS 5108 chassis  < THAT’S 160 BLADES WITH ONE UNIFIED FABRIC AND CONTROL POINT

Ethernet and Fibre Channel

•FabricSync < HIGH AVAILABILITY BUILT INTO THE UNIFIED FABRIC

–The UCS 6100 synchronizes their mac-addresses between them. It works along with FabricFailover feature to provide faster VNIC fail over for Bare metal and brings HA to Hyper-V virtual switch networks. It is always turned on.

•PVLAN support < SECURITY BUILT INTO THE UNIFIED FABRIC

–Layer 2 traffic segmentation within a subnet can now be achieved using PVLAN Isolated access in the UCSM. This allows customer to achieve vNIC level isolation which translates to VM level isolation using Cisco Virtual interface card in pass though mode.

•SPAN support on UCS 6100 < VISIBILITY IN TO THE UNIFIED FABRIC

–SPAN provides granular visibility in to the Ethernet and FibreChannel flows within UCSM for monitoring and troubleshooting

•Higher VLAN scalability (>1000) < SCALABILITY OF THE UNIFIED FABRIC

–Increased VLAN scalability from 512 in 1.3(1) to 1024 in 1.4(1)

•Direct connect Appliance < SIMPLICITY OF ADDING IP STORAGE

–Specialized IP Appliances such NAS filers and ISCSI storage can be connected directly to the UCS 6100 in End Host mode. This allows reduction in number of hops and latency for communication between server and IP storage.

•FC Trunking and port channel (in NPV mode) < INCREASE UTILIZATION OF FC JUST LIKE YOU CAN ETHERNET

–Allows trunking of multiple VSANs using a single FC link and FibreChannel link consolidation when using VSANs,

•Limited Direct Connect FC Storage < ADD STORAGE SCALABILITY WITHOUT INCREASING SAN COMPLEXITY

–FibreChannel storage can now be directly connected to the UCS 6100 with default zone policy (No zone configuration allowed in the 6100 but can be inherited from an upstream MDS switch).

Security

•KVM security enhancements < SECURITY IN OPERATIONS

–Multi-user KVM access has new controls that allow the first user to allow/deny or control the permissions of subsequent sessions.

•AAA – Active Directory group support < GRANULAR RBAC

–Groups defined in active directory can now be mapped into roles within UCS Manager.

•AAA – Multi-authentication support < FLEXIBLE RBAC

–UCS Manager now supports concurrent authentication using different authentication schemes such as Active Directory, TACACS+ or RADIUS. Concurrent authentication with multiple instances of the same scheme, such as multiple Active Directory domains, is also supported.

Monitoring

•SNMP GET support for all UCS components < EASIER INTEGRATION

–SNMP support has been extended to provide query (GET) support for all UCS components. The new MIB files can be accessed athttp://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml. Select UCS Manager under ‘Unified Computing’.

•UCS 6100 licensing enforcement/warnings < EASIER COMPLIANCE

–A new GUI based workflow for licensing management is available and licenses are enforced with warning messages.

•Syslog message classification enhancements < EASIER SYSTEMS MANAGEMENT

–New UCS labels allow easier filtering of syslog messages.

Stateless Computing

•Scheduling of service profile changes < OPERATIONAL FLEXIBILITY

–Through the use of maintenance policies, service profile deployments can be scheduled for a later time. In addition, the number of concurrent profiles that are being applied and the total number of profiles applied during a particular time window can be controlled.

•Impact analysis of configuration changes < HELPS CHANGE MANAGEMENT

–A simple “pre-flight check” compatibility check allows customers to recognize potential compatibility issues before applying a service profile to a particular server.

•CIMC IP address abstraction < MULTI-TENANCY AND OTHER USES

–In addition to the CIMC IP address for the CIMC on the server an optional management IP is available with the service profile that can move with the service profile when it is moved to a new server.

Usability

•User labels for managed objects < MAP SERVICE PROFILES TO WORKLOADS WITH SIMPLE LABELS

–Service profiles, servers and chassis have custom user labels that can be applied. These user labels can be displayed, sorted and filtered through the UCS Manager GUI.

•Direct upload of firmware image files from UCSM client < THIS IS ALL MY CHRISTMAS’S ROLLED INTO ONE!  THANK YOU ENGINEERING!

–The need for setting up SCP/SFTP for image file uploads is now optional since a direct upload from the laptop or other UCS Manager client to UCS Manager is now possible.

New Hardware Features in Release 1.4(1)

This release adds support for:

•UCS B230 server blade

–UCS Manager now supports the newest blade in the UCS B Series, the UCS B230 which is a 2 socket, 32 DIMM slot half width server with two optional SSDs.

•UCS Manager support for UCS C-Series

–The UCS C200, C210 and C250 servers can now be managed directly from UCS Manager. Integration details are available in the C-series server installation guides. Please contact your Cisco representative for additional information on connectivity and compatibility requirements.

•Fabric Extender Transceiver (FET-10G) between the fabric interconnect and fabric extender.

No related posts.