Virtalus HyperCX Bento is a hyper-converged Cloud platform designed to provide Infrastructure as a Service (IaaS). Virtalus started as a Private Cloud provider, but now a days it also provides Public Cloud based on the same technology leveraged on HyperCX Private Clusters. Users can request Virtalus for private clouds, or simply register and start using resources from Virtalus own managed public cloud. Besides of this, owners of a Private HyperCX Cluster can convert them into a Public Cluster without intervention from Virtalus.
Virtalus HyperCX Bento is the newest HyperCX architecture, Virtalus no longer maintains the original HyperCX stack. In this documentation, the term HyperCX alone will always refer to HyperCX Bento.
Being a hyper-converged platform, a Virtalus HyperCX cluster integrates the following components:
Network Subsystem: Provides connectivity to all cluster components and some workloads. Constitutes physical components as well as virtual components. This components can vary depending on the specific deployment. When Virtalus deploys in one of it's data centers, Virtalus own managed switches will be used, but this is optional when deploying on-prem for a user. In case of the firewall, something similar happens. By default, Virtalus recommends to use it's own virtual routers. These devices will provide connectivity to all the critical cluster components, and the default virtual network that is created using private IPs. These virtual routers can be fully replaced by physical firewalls if desired, or use together to physical firewalls.
Management Subsystem: HyperCX leverages an extended monitoring system tightly integrated to all its components. This system will send monitoring data to Virtalus central management servers, allowing Virtalus to constantly monitor the health of every cluster. Besides of this, a local version of this monitoring system will be installed locally only on Bento clusters, accessible to the cluster's administrator to check advanced metrics not available through the orchestrator. This system offers:
- Proactive and reactive monitoring.
- Failure, accounting and performance monitoring.
- Active and passive probes.
- Optional email notifications.
Storage Subsystem: A Software Defined Storage (SDS) solution deployed as a Storage Area Network (SAN) is used with the following characteristics:
- Bare metal installation.
- Replicated data.
- Optimized performance for VMs and containers.
Orchestration Subsystems: This subsystem provisions and manages resources on the cluster. It also handles more advanced features like High Availability.
Compute Subsystems: HyperCX being a hyper-converged platform, shares the same cluster between workloads and the rest of the subsystems (storage, management, compute and orchestration). The compute subsystem offers KVM Virtual Machines and LXD containers. KVM Virtual Machines are mandatory and will be available on every HyperCX cluster. LXD containers are optional.
So far, we have mentioned HyperCX Bento and miniBento. HyperCX Bento is Virtalus flagship architecture, designed to handle big and critical deployments. It is fully redundant and the smallest configuration starts on three nodes. There are use cases where smallest deployments are needed, like Edge Computing and development applications. HyperCX miniBento is more suited for these cases since it can be built on top of a single node (or more). In order to make it as lightweight as possible, High Availability is not supported on miniBento deployments. The local monitoring system is only available on HyperCX Bento configuration, although both Bento and miniBento will be remotely monitored. The last major difference is that HyperCX Bento is designed to be scaled out up to hundreds of nodes, but this is not the case for miniBento. Notice than in this case the limiting factor is notthe technology, but the lack of redundancy. Since HyperCX stores all the workloads on a SAN, and there is no redundancy on miniBento, if any server or any drive fails most of the information can be lost or corrupted, so it is not feasible to scale out miniBento instances since the more hardware running the more chances of failure. The following table summarizes the differences between both:
|Minimum amount of nodes||3||1|
|Integrated Monitoring System||Yes||No|
For any Cloud Deployment model offered by Virtalus, the hardware can be installed on-prem (inside the user's facilities) and off-prem (hosted in one of Virtalus data centers). Each approach has advantages and disadvantages, some of those are summarized next:
|Less Internet BW required||Faster deployments|
Regarding the installation mode, two options are available: Full Stack and Software Only. The only difference is related to the hardware provider. A HyperCX cluster delivered by Virtalus including the hardware is a full stack configuration. On the other hand, the user can provide the hardware and Virtalus will build the cluster. This is called a software only configuration. Full stack configurations can be deployed inside Virtalus data centers (off-prem) or be shipped to different locations (on-prem). HyperCX software only clusters on the other hand can only be built off-prem, inside the user's facilities.
The following documentation is designed for HyperCX users. Most of this documentation, except for the Public Cloud section, is meant for administrators of a Private Cluster. This configuration exposes all of Virtalus HyperCX features, which are considerably more, hence the reason why there is a single section for Virtalus Public Clouds.
If the goal is to quickly start spinning up virtual instances, you should go to the Quick Start Guide