Category Archives: JSON

IT Service Brokerage: Technical Mindset – Infrastructure

Leave a reply

“…if an application moves from an environment where disks/volumes are mounted using WWNNs/WWPNs as end-point IDs (fibre channel) to an environment with IQNs as end-point IDs (iSCSI) we often have to re-validate and re-engineer.  If the application were to list its own requirements it would actually just be something like ‘xGB block storage, isolated, with <performance guarantee 1> and <performance guarantee 2>’.  There would be no mention of WWPNs or IQNs, fibre channel or iSCSI.  The list above is the type of [automated/attached] description needed that would help make the application portable.  It fits into a trust-based model (aka Promise Theory)…”

The above is an excerpt from my recent post on our Cisco UK & Ireland blog.  You can read the full post here: http://gblogs.cisco.com/uki/it-service-brokerage-technical-mindset-infrastructure/

 

Advertisement

Capturing DevOps – Part 1 of 2

1 Reply

Ok, so “Capturing DevOps” might be taking it a bit far as far as this post is concerned!  DevOps, however, is a subject that I’d like to go into more detail on so that’s why this is part 1 of 2… but for now I’d like to stay true to my promise of showing how to capture the XML sent to and from UCS’ RESTful API.

Capturing raw XML is a relatively straight forward thing to do to be honest.  At the end of the day, a contiguous block of XML is ordinarily wrapped in a common IP packet and therefore capturing a relevant IP packet and looking into its payload data will give you a lot of what you need.  This is a little different to CLI and carriage returns…  Wireshark can help with IP packet capture, including XML (or JSON) data of course.

XML becomes useful to a DC or Infrastructure SME when you can look it as a human with a basic understanding of what is being sent/received and then work back from there to translate it into something less like computer code.

goUCS is a tool that can help with that when looking at UCS.  goUCS has quite a wide remit.  Its purpose is to capture actions and make them repeatable (i.e. adding variables where needed).  We are just going to use it to do the capturing bit today.

Where to start?  First a snapshot of what goUCS is in a little more detail… I’ll copy and paste this because… well, it’s easier:

goUCSDesc

Secondly, I’ll just mention that the setup is straightforward enough for me not to bore anybody with the details.  Download zip, extract it, add folder to system path.

Thirdly, let’s party!  Here are the steps in straight-talking language:

  1. We open a UCS Manager session.
  2. Within a cmd window we go to the extracted goUCS folder and navigate to the “bin” sub-folder.  “goucs filterlog logtail” is then entered.
  3. We go back to UCS Manager and perform a configuration task in the GUI that we would like to view the XML for.
  4. We then go back to the goUCS window and then copy & paste the XML dump into a text file.
  5. We use the XML as we see fit.

Straight-talking images:

goUCSFlowImage

Now, “We use the XML as we see fit” is quite an interesting area.  UCS has a python SDK that you can download that’s very capable – something to maybe take a look at…  However, a colleague of mine decided that he wished to create his own ‘focused on what we want to’ SDK that can be used across all of the RESTful APIs within our data centre stack including the UCS API that we’ve focussed on above.  This allows us to move to a model of programming across hw and sw infrastructure components all from one tool (notwithstanding that UCS Director is actually the right option for that kind of control…).  The capturing and storing of XML for given actions was part of his app development.  In the next part of this update I’ll be running through how that app works and practically demonstrating what ‘DevOps’ is about.  Until then, I’ll leave you to do some batmailing on your batphones!

Model-based?

Leave a reply

“Model-based” sounds like an IT marketing term if ever I heard one.  It has a systematic, structured and business-like ring to it…mr-burns-picture

If you asked one hundred different people what model-based means as far as data centre IT systems + management is concerned you’d get…hmmm… I’d guess about… 63 different answers?  1 of which would be noted down as a catch-all ‘not sure’ covering 38 of the people!?

Even with this in mind, I think we’ve actually touched on a system that comes as close as it gets to ‘model-based’ in the date centre without it causing the person stating the point to blush from a ‘did I really just say that’ feeling!
Cisco Unified Computing System (UCS), a system comprised of HW+SW, empowers by providing re-usable and hierarchical ‘building block items’ with linkages to these items framing a HW+SW infrastructure delivery in a differentiated, yet uniform, way.  ‘Synonymously speaking’, it’s what would generally be seen as correct SW development techniques applied to provisioning and monitoring actions against both the SW and HW of a compute environment.  We touched on the UCS PowerTool‘s hook-in (MS PowerShell) to the UCS XML API in the last post and that’s essentially the starting point for this one.

So, let’s take a look at an image from the last post: UCS PowerShell Network

We essentially have an application above which is written in PowerShell.  The application’s purpose is to instruct a UCS system, via its HTTP-based API (‘connection-to-UCS’ lines are omitted), to create policy associated with characteristics defined using variables by the application’s user.  Those variables, in some cases, refer to the pre-defined ‘modular and re-usable building blocks’ mentioned -> e.g. A “MSWin-Ethernet” QoS Policy can be picked out in the above.  This may be one of many pre-defined QoS policies…  We have an example ‘boxed-up’ automation of a provisioning action which induces a shift towards a provisioning model that aligns to:

  • Speeding up the deployment and re-purposing of infrastructure.
  • Increased accuracy and utilisation of infrastructure.
  • Reduced downtime and Mean Time to Repair (MTTR) by modeling using dependencies of lower-level items -> i.e. packaged, abstracted and portable.

 

However, the application itself is making use of a number of ‘code packages’ or modules that simply aren’t visible above.  In this case its PowerShell, and PowerShell code modules are called cmdlets.  cmdlets are generally/mostly compiled before you download and use them and they are essentially what provide the portability + simplification of PowerShell which makes it so useful and beneficial to [Data Centre] Infrastructure SMEs etc.  They can help bridge the gap between the expertise of [Data Centre] Infrastructure SMEs and Software Development/Programming SMEs to a certain extent.

To provide a view of what’s going on under the hood, take a look at the following:

1. An example PowerShell line (create Service Profile Template – 1st PS line):

SPTPowerShell

2. ‘Expanded’ representation:

ModelBasedBreakdown

3. Linkages between the expanded items and the underlying UCS model:

Model Linkage

Now, if I wanted to work back the other way, in a way that could be thought of as being closer to a developer’s viewpoint, we need to be aware that the cmdlet being referenced above would in essence be part of a wider action.  The action would be to set up a HTTP[s] session with the UCS system and then send pre-crafted XML with text defined above inserted as variables.  To really see ‘under the hood’ we would need visibility of the XML that the cmdlet is actually causing PowerShell to send.
There are ways to do this.  One way is to capture what gets passed between UCS Manager and a UCS system’s API.  The easiest option to capture this XML goes by the name of “goUCS” and I’ll be showing a use of that particular tool in my next post.  At least I assume that you would prefer to not be spending hours with WireShark captures… or indeed looking at some somebody else has done…

The XML gives us the ‘raw code’ to tap into an underlying model-based environment -> i.e. in this case it’s a Service Profile Template along with its ‘building block’ dependents.  The XML and the underlying system-level abstraction is the magic stuff!

What’s the bigger picture?  It’s not enough to ‘software-define’ systems simply by adding common/standard ways of interfacing and communicating with them without having links in place between the ‘instructions’ sent and the different hierarchies of variable items underneath the interface.  An inability to add new ‘links’ to unique/innovative attributes that sit at a hardware level will also limit innovation in the future and restrict a sustained direction of statelessness and abstraction.  Commoditisation shouldn’t be an end goal in itself, it should be part of a wider plan.  Adding a HTTP-based SOAP/REST API and expecting it to mask the fundamental architecture of a system is essentially flawed.  To sum up: ‘Software-defined’ will not always necessitate a ‘Software-only’ mindset or be benefited by it.

Run that last bit by me again

Leave a reply

Near and far: UCS Service Profiles and Roles The image above is a simple representation of the ‘true and absolute’ technical convergence that Cisco’s Unified Computing System (UCS) introduced in 2009.  This led to some considerations regarding roles and demarcations between subject-matter expertise (SME) within ICT Departments/Organisations.

Consolidation, rationalisation, convergence.. whatever apt/buzz word you want to use, ICT has continuously made use of this general concept to move things forward and be more efficient.  From Cisco’ s Architecture for Voice, Video and Integrated Data (AVVID) way back when to LAN and SAN convergence underpinned by the innovation around Data Center Bridging (DCB) and to a certain extent IP-based storage protocol evolution, there are benefits to customers and vendors when moving forward using this general construct.  Vendors can focus their R’n’D, engineering and support efforts on what matters (and also monetise innovation), customers and providers can ‘do more with less’ and more-easily adapt to the ever changing nature of their business or sector.

A couple of general technical themes that slim technology down are  1) Modularisation (inc. ‘re-use’)  and  2) Taking an [often physical] element and emulating it in a new logical form, whether that be abstracted over a [new?] common foundation or by merging two elements using the ‘pros’ of both/all existing paradigms and [hopefully] dropping the things that aren’t so good.

Other than the maturing of these technical shifts, humans are without doubt the main hurdle to deal with.  If we take Voice, Video and Data convergence in the ‘noughties’ we were taking very distinct areas and bringing them together with one area appearing more influential; a case of adapt or risk becoming irrelevant -> individuals with positive and/or negative intent went against the grain…  Back in the DC, UCS didn’t necessitate anything quite as a drastic as that but there is/was potentially at least some blurring of the lines.

One point of control, three areas of expertise… you choose the demarcation lines between humans (if any): UCSM1

 

Holistically speaking:

In addition to some obvious reasons for the lack of a need for severe changes around the alignment + skills of people when adopting UCS, there was also a shift in how we interfaced with the infrastructure… and that’s really the crux of this post and what will make new systems and market shifts easier and easier to adopt… Skills Meeting

UCS introduced a clear single point of control with an associated API for Compute, LAN (Access) and SAN (Edge/Initiator).  Other than the obvious uses of this API; Unified Computing System Manager itself (i.e. the tabs above) and other mainstream software packages with wider remit, we have seen ‘raw’ applications of the native HTTP-based interface and also some adoption of a Microsoft PowerShell option that wraps common API calls into “cmdlets”.

One of the notable differences between convergence today and the convergence of the past is an ‘alleviation’ offered by programmability and standardised scripting + automation.  Taking a broader look at expertise areas, there has been a ‘meet in the middle’ occurring between Infrastructure teams and Programming & Development teams (i.e. not only within the infrastructure bit).  This effort to meet in the middle encompasses some skills development focused on common and universal ways for people from different ‘infrastructure’ SME backgrounds to be more similar to each other than in the past.

i.e. Less of this 😉 (image courtesy of a very talented colleague…):

Traditional Roles

 

Ok ok I get it!… an example please?

Let’s take the creation of a UCS Service Profile.  I’m a Network SME… I might create these items so that they can be used within one or many Service Profiles:

  • A new org/container.
  • Segments (aka VLANs today) to be supported northbound of UCS and made available within the system.
  • MAC Address Pools – Using ‘my own’ prefixes so that I can identify zones/workload-types in a granular and structured way vs. standard non-hierarchical defaults.
  • virtual Network Interface Card (“vNIC”) templates and their associated characteristics such as the VLANs trunked to the OS/Hypervisor, QoS policy, pinning policy, etc.
  • “Dynamic Connection Policies” to bring together a multi-vNIC connection profile that can be associated with a given x86 node/service profile/service profile template (e.g. ‘I want those pre-defined 6 x vNIC templates and those pre-defined 2 x vHBAs as an over-arching template’).
  • etc.

I’m a Compute SME… I will make use of the items created by the Network SME (and others from a Storage SME) and add to them to complete a Service Profile (or SP Template):

  • UUID Pools – Using ‘my own’ prefixes so that I can identify zones/workload-types in a granular and structured way vs. less-structured ‘burned-in’ defaults.
  • Re-usable BIOS policies for different workloads.
  • Boot-order configuration templates inc. boot-from-SAN for different workloads.
  • Full firmware packages.
  • A Service Profile Template including an option from each of the above and a pre-defined dynamic connection policy (or selected vNIC/vHBA templates).
  • Individual Service Profiles spawned from a Service Profile template.
  • etc.

However, if both SMEs wished to interface using the UCS HTTP-based API they could adopt an approach using Microsoft PowerShell (aka “UCS PowerTools” in this case).  Here’s a subset of configuration from each of the lists above:

Network SME:

UCS PowerShell Network

Compute SME:

UCS PowerShell Compute

It all looks pretty consistent to all people involved now doesn’t it?  Static text mixed with variables for the bits that we want to define… all ‘translatable’ if read through to most involved.  The same would apply if we used XML/JSON and a REST/SOAP mechanism instead… which I will detail further in my next post (a bit too much for this one).  These common and universal ways of interfacing with the system(s) can often make it easier for people of different backgrounds to interpret what other SMEs are having to consider and therefore configure.  The view is of the ‘basic requests’ and not of the complexity associated with the old/existing views into technology silos… inc. GUIs and the frightening introductory view that they give!