Magic: Indirection at its best
In Day 3 of the UCS Training, I had another moment of epiphany (in addition to Brush up your drawing skills): if you use its Indirection, Abstraction, Pool and Policy capabilities then you should have limited hands-on after it has been deployed. This means you are codifying system complexities (ie. not UCS complexities, but IT system complexities like SAN WWNN, WWNP etc) once, then re-using: this might (should?) have an impact on the operational model, but that’s for another blog post. What do I mean by these four UCS approaches, and why should you care?
By Indirection I mean simple, familiar things like giving a VLAN a name as well as a number. “DMZ” is VLAN “3″ – this week, anyway. You configure the DMZ blade NICs to attach to the “DMZ” VLAN, not to attach to VLAN 3. Next week when the DMZ VLAN ID needs to change, you don’t have to configure any blades or server profiles, you just change the VLAN number for “DMZ” and all blades and server profiles get the update. Easy! This is very similar to vSphere port groups where the name “DMZ” identifies a configuration and you attach multiple virtual machines (their vNIC) to the same configuration (the vSwitch or port group). The alternative is to configure every end-point (vNIC) with all the settings available in a port group (e.g. VLAN ID) – but of course, to make any changes with that model you have to change EVERY instance instead of ONE configuration: operations, in the pursuit of efficiency, likes making one change to effect multiple nodes and this is enabled by Indirection.
Abstraction is similar to indirection, but in this case we’re talking about hiding a lot of detail about on component, from another. The main use of abstraction in programming is to create replicas of one object whilst allowing minor variations in the actual implementation. An example is the abstraction of a car: all cars are of a similar abstraction (body, wheels, engine) but all can implement each abstracted feature differently (e.g. Ferrari vs. Lada). In the UCS sense, a Server Profile is an abstraction: it contains the form and structure of what makes up a blade in terms of configuration, but when the blade is actually configured then minor implementation details (e.g. MAC address) can be uniquely implemented for each instance of that server profile. For example, all eight blades in one UCS chassis can be children / instances of the same abstract server profile, but have unique MAC, WWN, UUID attributes. Operations, in the pursuit of less variance, loves repeatable patterns which are enabled by Abstraction.
Pools are what makes UCS scalable with minimal operational / manual interference. Instead of having a spreadsheet of MAC addresses, create a pool in the UCSM with a starting MAC address and a size (128 MACs? You decide!), and then attach a Server Profile to the Pool so that any instances of that abstract Server Profile will take a free MAC address from the pool. Same for WWNs and other attributes. Operations, in the pursuit of effectiveness, seek to scale their throughput (projects, changes) with lower operational expenditure, and this is enabled by Pools.
Finally, Policies provide some sensible operational policing in the UCS system. For example there is a qualification pool that you can attach to a server profile which means that any blade attached to that Server Profile has meet certain criteria such as size of memory. Boot policies are also included to ensure that blades, as defined by their Server Profiles, have the correct boot sequence like Boot from SAN for truly stateless computing. Operations, in the pursuit of hot-swappable compute, network and storage to increase availability and decrease MTBF love this approach.
In summary, UCS enables great IT operations because it helps efficiency, effectiveness and throughput whilst reducing variance, and will be a corner stone of high performance operations giving the business a competitive edge: this isn’t marketing, it’s an operational fact.
Related posts:
[...] This post was Twitted by vCTO [...]