Our use case, from our point of view, is that we installed this product in data centers for our customers. I work with six customers currently, and I have to set up the data centers for each of them. For one of them, we run the Cisco UCS Manager. So I have hands-on experience with the setup from end-to-end.
Usually, we are called by clients specifically about product suggestions. I often personally recommend Cisco UCS because of the high availability. The setup time is quick compared to other products in this category. When we are contracted we have to set up the network, the storage, and other parts of the environment. That means a network and storage link for each and every chassis. But here, because of the configuration of Cisco UCS, we need just one link for all the chassis. This helps us make for quicker delivery time.
We also monitor the systems, we install and keep spare blades for each and every chassis. Just one or two blades are sufficient for the entire environment. That way, we can easily manage system maintenance. Also, the failover and the profiling system is good with the Cisco product. You can just move the profile to the new blade so that it will start working with the new configuration. This makes it easy during maintenance.
The ease of management is certainly the most valuable feature in this product.
So far the only challenge we face with Cisco UCS is during firmware upgrades. If it happens that there is a failover, and we need to change something in the system, this is where we can run into problems. We can't upgrade the firmware for each component one-at-a-time. It is not a method that will work in a practical way in a larger or global network.
Nowadays it is some sort of a status symbol or a business necessity for a customer to be in various geographical locations. Because the client can have locations in Australia and the U.S. — in different regions of the world — that tends to make the maintenance of the firmware more difficult. The various business locations offer challenges in that way.
Usually, when we procure the blades, everything has the same firmware level. This makes sense and is fine if installing in a singular location and for new installations. Everything will match. If it is a new installation and the hardware was not procured at the same time, the firmware for all the components can easily be upgraded because it is still before the implementation.
But later — say after one year — a customer needs to expand. If we are procuring a new blade, the new blade will come with the new firmware. When the new blade is mounted into the chassis, the old alignment will not understand the new blade because it has new firmware.
In that case, you need to downgrade the firmware for the new blade or upgrade the firmware for the entire environment. During the firmware upgrades, we would definitely need to take downtime in some cases and the downtime would take too long. We face that challenge all the time in having to choose which path to take during the upgrade. But because of the obvious issues with upgrading the entire environment, it often looks like a better solution to just downgrade the one new blade. We need the option to downgrade or choose the firmware for the component because we cannot upgrade the entire environment. In many cases, we cannot take the downtime for the entire environment because of what it means to the network and the business.
We should have chances to work with firmware levels in one or two firmware versions and it should be easier to do. Everyone would be comfortable with that. Otherwise, in some cases, there is no point in providing a new blade. Customers will hopefully grow and need new blades. We don't want any extra risk with downtime.
So Cisco should make an improvement in the firmware upgrade process. No one is providing this kind of solution. But if Cisco would improve that firmware issue, that would be great.
A new feature that I would suggest is to have the possibility of different types of connections. Within the full-width blade, there are two types of blade: full-width and half-width blade. In the full-width blade, when one link fails, the other link will take care of the entire load. The half-width blade doesn't have that kind of input. It has only one link. If one link goes down, the entire blade goes down. So Cisco should include the feature like that in the half-width blade so it functions more like the full-width blade and is not prone to failure.
I have used UCS Manager for almost six years.
The help that we get from Cisco support is really good, but there can be nuances with the incompatibilities in existing structures that cause complexity. These can take some time to resolve. But the resource is dependable.
The initial setup is complex. I will have to spend a lot of time planning the actual implementation. When we execute the plan it will take about two months. The recommendations of the product to the client, the acceptance and the procurement could take as much as four months. But once they deliver the product, we will take a maximum of six to seven weeks to finish the implementation. This is the outlook for the plan but the implementation does not always work so smoothly.
On a scale from one to ten where one is the worst and ten is the best, I would rate this solution as an eight out of ten. I use the UCS Manager and I think it is a good solution.
