At VMworld USA, we met customers to discuss their plans to move to a more automated form of IT delivery.
When we talked about Hitachi Converged Platform called UCP Director, the awareness should have been better. That’s being honest.
In this blog I propose that Enterprise Cloud is far superior on Hitachi Converged Systems than it will ever be on any other vendors converged platform.
This is not driven by FUD or Koolaid. When I joined HDS I didn’t understand the capabilities of our converged offerings the way I do now.
I will make the case to try and address the gap in awareness and convince you, The Reader.
When we talk to customers now, it doesn’t take them long to realise it, and frequently they revert to existing converged vendors to ask “Do you have this feature ?”. The answer is normally No.
The superiority is simply put, due to the relative features and functionality of different products. It’s not a case of Hitachi having a shinier badge or more “go-faster stripes”.
Come to our booth and Challenge UCP !
I would like to invite customers, partners, consultants, competitors to come to our booth and challenge UCP.
I believe you may leave shocked and full of consternation wondering why Hitachi is not the market leader. I discussed this with a high profile VCDX at VMworld USA and he was very surprised at much of what I will discuss in this post. He suggested I should blog about it so here we go “R” ;-)
If you want to take the challenge I’d love to talk to you, wherever you come from. All I ask is that if you’re a blogger and I convince you that UCP is a more feature-rich, operationally advanced and consumable platform, that you write a blog saying so ?
Let’s touch on some salient points which provide evidence for this to be the case.
1. “This is not a plugin, I Repeat, This is not a Plugin”
Unlike other platforms out there, we ship our converged platform with a full software suite installed by HDS on a discrete (isolated) management cluster.
This is not a plugin! - we have vCenter storage plugins already which are powerful - UCP Director is not that (even though ultimately a vCenter plugin is one small element of it).
The management suite contains all the elements to allow you to manage (and orchestrate) compute, storage and networking directly from inside vCenter, with actions presented specific to the object you’re clicking on i.e. cluster, host and so on.
Why ? So converged systems don’t have to be as complex as solving Nuclear Fusion, like some competing solutions :-)
So you can still fire up our element managers if you need to, but we reckon for 90% of operations its's unnecessary.
UCP Director is the product name for our converged stack with IP created by HDS. It is also used for the Software that runs inside vCenter and System Center. A single name for the system but also the orchestration software.
UCP Director enables a level of management simplicity you might associate with a hyper-converged solution, but now you get a true Enterprise-class converged platform, without any of the issues that hyper-converged systems can bring about.
This makes UCP Director compelling, as the reduction in operational overhead is why a global SI currently using VBlock has adopted UCP Director to reduce cost and complexity and open up virtual and bare metal orchestration. However they don’t know the half of it yet !
2. UCP is Network & Hypervisor-agnostic!
- UCP Director supports a number of different combinations of hardware.
- You can run a Hyper-V or a VMware POD on the same hardware models.
- From a manageability perspective both systems are identical. (Note those running a dual-hypervisor strategy)
- The functionality inside vCenter or System Centre is the same. (More below)
- You can rebuild a VMware POD as Hyper-V and vice versa.
- You can use Brocade or Cisco networking.
- We find sometimes Brocade works best with certain SDN software like NSX where there may be a conflict in customers eyes.
- HDS doesn’t mind which route you go. We preach the mantra of customer choice.
- With HDS there are no vendor or federation politics at play.
The Cisco option is more scalable and there are no issues attaching a UCP Director to a Cisco Core with Brocade or vice versa. That’s all documented and delivered all day every day.
3. We have the most feature-rich blades
That’s a pretty strong statement. Let’s back it up.
Most customers don’t easily switch servers unless there’s a compelling reason. What if you cannot virtualise an application, or maybe you want to split some blades out of the converged stack for non-virtualisation use cases such as Docker ?. You can use a concept called custom service templates.
LPARS and SMP
There simply are no other blades in the x86 market that offer Logical Partitions with Hot and Cold Standby, as well as Symmetrical Multi-Processing.With SMP you can combine multiple blades together across multiple chassis if required. With LPAR you can split a single half height blade into 30 partitions. You can also LPAR an SMP blade.
Use Case1: If you want to virtualise 30 Oracle servers with 2 dual socket Enterprise licenses maybe you can’t for licensing reasons. Why not create 30 LPARs and then just license 2 sockets ?.
Use Case 2: Why not use Docker on LPARs with Hitachi N+M hardware HA ?
Note that even though we can use so-called “custom” blades we still collect all the health, task and events directly into the vCenter database just like we do for “regular” blades, storage, networking devices and all events and tasks. So you get the monitoring benefits always.
Is your SNMP monitoring engine already pointed at vCenter ? Then job done !
Hitachi provides more flexible options than HP, Dell, Cisco, IBM or any other vendor.
4. How is UCP Director even possible ?
- Hitachi owns the IP for the blades.
- Hitachi designs and builds them
- Hitachi controls them using an API designed by Hitachi.
- Hitachi designed the API for Storage.
UCP Director talks to these element interfaces and also programmatically controls fabric switches and ethernet switches. So UCP-D programmes VLANs on host uplinks and also on switch ports.
5. API consumption model
Thankfully when customers ask can we control the entire converged stack using API calls the answer is Yes. This has been a design features since Day 1.
There are more functions exposed via the API than are possible inside vCenter and you can service chain these as
My colleague Anil Erduran (Microsoft MVP) built a Powershell wrapper recently to perform actions against a Microsoft HyperV UCP. He was creating clusters, provisioning storage, polling events and so on.
We lifted that script and ran it entirely unmodified on a VMware UCP POD. Of course it would work?
There are around 350 individual REST API calls that can be made against UCP Director.
A Cloud Management Platform like vRA or Azurestack orchestrating clusters, storage and infrastructure on different resource cells running HyperV, VMware (and other future hypervisors) is trivial thanks to UCP Director API.
6. Feature parity between all interfaces
Flexibility defines the different options; I honestly can’t always tell customers them how or what to use UCP Director for. They are the experts in my view and they will decide once the options are presented.
7. So much for legacy storage lockin eh ?
When you order UCP director you can order it without storage. How is this even possible.
Surely this is sacrilege for the HDS account managers ? They must be pretty peeved at this ?
For a long time Hitachi has had array virtualisation (partitioning) technology.
We used to have this just in the high-end VSP but this technology now runs throughout the entire storage line. (Note you can also virtualise other vendors hardware behind the entire range too)
- take an existing Hitachi storage system and make partitions for UCP Director
- order a storage system with UCP Director and make partitions on it for non-UCP systems.
That’s also because the physical architecture involves storage decoupled physically into separate racks, by default.
Use Case: We have a recent use case where we are delivering a Cloud Platform to a Service Provider. The configuration includes two UCP4000 systems on Site A and Site B, sharing storage that is partitioned. The management platform runs outside UCP and each UCP “appliance” is controlled using the vCenter (UCP Director as an endpoint) contained therein.
8. What about the architecture ?
Some decisions were made early on about UCP Director.
The management cluster contains it’s own vCenter, AD, HCS, HTnM, WDS, WSUS, SRM servers etc. Hitachi provides UCP Director Operations Centre (DOC) controlling federation of multiple UCP's as well as site failover.
UCP Director uses separate partitions on the storage to isolate customer applications from the UCP management VMs.
UCP Director uses auto-deploy and service templates to keep blades consistent and reduce configuration drift to zero.
Hitachi has made it possible to modify ESXi images and add/remove VIBs directly inside vCenter (as well as using API/PowerCLI).
9. The Service Template
Back in the day people thought what Cisco did with the server profile was clever. It was but we have enhanced that significantly.
Here's some slides to illustrate the point
This is what a Hitachi service template is made of:
Here's an example of a cluster deployment, made easy in UCP Director via a single REST call:
This is what happens behind the scenes:
So you could stand up a 10-node cluster with a single REST call. Just provide some documented metadata and it's trivial. I could go on and on so suggest you come for a demo and test whether what I say is true.
If you come and talk to us you will get to see a real UCP system on our stand and talk to some of our Hitachi server experts. I am working hard to provide a prize to those who come and take the challenge. More details coming.
Until then, enjoy VMworld .......