Red Hat Hyperconverged Infrastructure - based on our leading OpenStack and virtualization platforms - provides co-located, scalable, software-defined compute and storage, driven by Red Hat Ansible Automation on economical, industry-standard hardware.
Red Hat Hyperconverged Infrastructure is valued for its compact size, making it ideal for small configurations. Users appreciate its real-time automation capabilities for R&D workloads. The consolidation of management in a single console is highly regarded. Users find the system stable, scalable, and commend its support and regular updates. The ability to add diverse services is also noted as beneficial.
Red Hat Hyperconverged Infrastructure is primarily used for running legacy applications, desktop as a service in R&D, and various verticals like banking, oil and gas, and retail. It supports virtualization workloads, computing, and databases. Environments are set up with x86 servers and 10-gigabyte networks. It offers flexibility for deploying diverse applications, including proprietary products, acting as a small-scale cloud for organizations.
Red Hat Hyperconverged Infrastructure is described as highly scalable by users. Some report scalability reaching up to 64 loads, supporting large numbers of R&D professionals. Users appreciate its scalability and stability; others mention potential limitations in certain setups, leading them to opt for alternative options. Various organizations size echoes positive impressions about scalability, indicating adaptability across diverse demands. Its capacity to expand by adjusting component sizes seems favorable based on user experiences.
Red Hat Hyperconverged Infrastructure was previously known as Red Hat HCI, Red Hat Hyperconverged Infrastructure for Virtualization.
We have a legacy application virtualized on top of the solution. It is our own product. We select what we want to run there. It is not possible to run all kinds of software because of the setup. We run a server application. For us, it is like a kind of small cloud.
The most valuable feature for us is the size. We have a small, compact model. It does not have any different separate management because management is built into our engine. Our product has its own problems because it has its own manager inside the cluster. That poses some limitations. It is also a problem. The size of the hardware is what we need because it is very good for small configurations. But this gives us three to six servers in principle.
This product is not so stable. Maybe it is just not mature enough in its development. When we upgrading from one version to another, there have been some hiccups. There have been a few times where upgraded features cause changes that make problems with existing implementation on the deployment side.
I'm not sure if I really need any new features in this product at this point. For us, it is a fixed solution. It's not a full-blown solution and doesn't need to be. It is not really a cloud product, but we use it like some kind of cloud in a box. It is very limited in our use case.
It has limited capability in general. You can not really have something like private security domains. Or there are so few servers that you can not really use the different kinds of applications you could with different physical servers. So you cannot select the kind of security that you can have on a cloud with separate layers.
We have worked with this product for a little under two years.
New features that seem to be small improvements have caused some hiccups after upgrades. As you upgrade from version 1.5 to 1.6, the new iterations of existing features should not cause changes to existing versions of that feature that create problems in operation. It is not like when you do a full version upgrade like from version 1.6 to 2.1. Bigger changes should be expected in full version upgrades and changes in existing features would be more acceptable and may be expected.
Scalability for this product would be changing the storage size. They claim that the limit is quite high. We do not need storage for this solution at this point, so I cannot say from personal experience if it is really scalable. As far as I know, our setup does not scale up to more than 12 hosts, which is far beyond our needs. If our need gets bigger, then most likely we would use a totally different solution in the form of a real cloud solution.
We have had some issues which take a longer time than expected for technical support to resolve, but generally, we have a quite good relationship with technical support. For some reason, Red Hat consults with us directly. We have some kind of preferred treatment.
Before this solution, we used to have a totally open-source solution that we used with our previous generation of products and that caused us some hiccups. It was free so there was no support. You were totally alone when you implement it and without commercial support that might help with problems that were encountered. The idea of making our change from the open-source to this solution is that we wanted to have some kind of commercial support when we needed it and a reliable product that worked. Of course, that costs something.
The initial setup is quite straightforward.
We are using consultants to work with us on the implementation. They are helping us out but we are the ones principally doing the implementation by ourselves.
My advice to those considering this solution is that they should get what they actually need. Red Hat is a big company and it is quite flexible in the kind of environment they support. There are other products we are aware of and tried, but they failed to support our application running on top of them. With the Red Hat KVM (Kernel-based Virtual Machine), we could play the tricks we needed to more easily to get our application to work. KVM was the key.
On a scale from one to ten where ten is the best, I would rate this product as maybe a seven. It is not bad, but it is not perfect.
