Written by:

Bas Stultiens

How easy is it to deploy the new Cisco HyperFlex?

Find out in the deep dive of our stack team

Nothing beats the smell of fresh iron. Especially when it comes to the three new Cisco HyperFlex servers we tested during a deep dive. Our goal? To find out whether it deploys and runs as smoothly as Cisco showed in their demo.

Ready to rollback

We now own a redundant set-up consisting of three HyperFlex irons. The plan is to reset the HyperFlex to factory settings each time we run into something. Even though Cisco provided a good demo, they were well prepared as always: fill out an IP address here, click there, next, next, done. As we will implement the HyperFlex at a customers’ site shortly, we want to know every detail of the process. This means we are ready to roll back and find out.

Create or expand

As soon as the HyperFlex is up and running, UCS manager as you know it can be used. In case you don’t: this is the local Cisco portal to manage servers. The only difference is you can now use UCS management deployer to create two workflows: create or expand. The ‘create’ workflow is used mainly to set up the system once it arrives. The ‘expand’ workflow helps to connect new servers to an existing HyperFlex environment. In our case, we start by using the ‘create’ mode to test the already installed environment.

The first thing we notice when we open the dashboard, is that our settings are unwilling to deploy. We receive multiple errors. The IP address is already in use, data stores still exist, and both the ESX and VM layer need to be reinstalled. Cisco’s promise about quick deployment only works when the machine arrives bare from the factory. Therefore, we decide to use an ISO to install the servers as if this were the case. Now we are ready to roll back!

Again, we run through the ‘create’ workflow. This time, all goes smoothly. Within four hours – including all roll backs – all three nodes are up and running. Policies, pools, the VMware hypervisor, and the cluster are all ready to use. The VMware environment does need some personal attention, though, as the storage has not been allocated yet. Also, the roll out needs some finishing touches with commands that do not fit within the automated process, such as creating VMotion networks and turning on SSH. There is still room for improvement here.

Saving 1 hour on 3 nodes

Although it is not fully automated yet, we feel positive. The HyperFlex deployment process is strict, and because of that it provides a sense of security about the steps you are taking. As soon as a box is checked, you can breathe normally again. In case mistakes are made, you don’t need to find the solution for it yourself – a big difference compared to the traditional FlexPod environment, in which errors can occur in different layers of the system and in some cases, you aren’t aware until days later.

The real time saver is hidden in the ‘expand’ workflow. Details such as admin, root, and clusters no longer need to be entered. Solely the IP’s and storage of the node will do. With a maximum of 64 nodes it does not support large workloads, but whoever does the math will notice a time saving of 20 hours.

Manual labor

Even though the HyperFlex takes a fair amount of work off your hands when compared to the FlexPod, a design still needs to be made, submitted, reviewed, and eventually implemented. Extensive knowledge of the topology is crucial. With each roll back, you need to start again. So, should you be doing a PoC in which a successful test is followed by a clean slate, be sure to keep the ISO ready for a clean install.

The final 10%

There are some downsides. The strict workflow forces you to fill out all details step by step. You can only move on to the next step once the current step is finished. This means you can’t do preliminary work. Even though certain steps in the workflow can be done separately – if you are familiar with Cisco UCS Manager and VMware ESXi. For instance, to move directly to the next step after an issue has taken place.

We also think it is a missed opportunity that we must allocate storage afterwards. It would have easily fitted in the steps of deployment manager. As it is now missing, we feel as though the final 10% has not been automated. But who knows what a future upgrade will bring?

Added customer value

The new HyperFlex saves a lot of time for our stack engineers, especially when they are familiar with UCS Manager. But it mostly adds value for our customers. Thanks to the HyperFlex, they are able to see the status of their network in a single dashboard. This takes away the need for a separate monitoring or alerting system.

The dashboard shows the overall health of the cluster, the amount of storage capacity is in use, the deduplication ratio and compression of the HyperFlex storage, and insights into high availability. Also, extending and upgrading clusters is simplified – upgrading is even possible without downtime through a web interface for both the UCS firmware and the VMware layer. We look forward to making our customers happy with this.

Co-author of this blog is Chung Teng Chiu from Itility.

Back to overview

Bas Stultiens

How easy is it to deploy the new Cisco HyperFlex?

Find out in the deep dive of our stack team

Ready to rollback

Create or expand

Saving 1 hour on 3 nodes

Manual labor

The final 10%

Added customer value

Your next step

Technology, Data, People

Bas Stultiens

How easy is it to deploy the new Cisco HyperFlex?

Find out in the deep dive of our stack team

Ready to rollback

Create or expand

Saving 1 hour on 3 nodes

Manual labor

The final 10%

Added customer value

Author's picks

Is NIS2 already stressing you out?

Container orchestration: a means to an end

Six success factors for a Cloud Center of Excellence

Want to stay updated?

Your next step

Technology, Data, People