This is one of a series of short posts looking at alternatives to VMware, following the completion of the acquisition of the company by Broadcom. In this post we review NodeWeaver, a commercial hyperconverged solution based on open source OpenNebula.
- Alternatives to VMware: Proxmox VE
- Alternatives to VMware: Scale Computing
- Alternatives to VMware: The Hypervisor
- Alternatives to VMware: Nutanix
- Alternatives to VMware: Introduction
Background
NodeWeaver is a hyper-converged infrastructure solution based on OpenNebula, an open-source server virtualisation platform. The software is designed for edge deployments where individual servers are commodity resources, and physical access is potentially limited or difficult. The company describes its product as a “nano-cloud” that is capable of deployment on small-scale servers, such as Intel NUC, up to traditional data centre infrastructure.
Nano-Cloud
Building for edge deployments requires specific architectural characteristics that enable the installation and management of systems in scenarios with little or no physical access. As a result, NodeWeaver includes features such as self-discovery, automated deployment, and self-healing capabilities (including distributed storage). The zero-touch design enables clusters to be commissioned and deployed with little operational experience.
NodeWeaver is a commercial solution and licensed by node (or server) irrespective of the capacity and capability of each node.
Installation
We installed a small NodeWeaver cluster on a pair of Intel NUC servers with 64GB of system memory each and Intel 11th Generation Core processors (i5-1145G7 running at @2.6GHz). Storage was provided by onboard 1TB NVMe M.2 SSDs, one in each server. We chose this configuration because it reflects a typical edge deployment where equipment is deployed in machine rooms or other spaces that aren’t controlled data centre locations.
The installation itself is relatively easy and conducted from the server console (there is also a zero-touch deployment option). Once completed, nodes can be configured into an existing cluster or used to create a new cluster for further expansion. Each cluster uses a common IP address for web-based management. Therefore, each node (which is given a serial number rather than a name) isn’t addressed directly.
We will review the capabilities of NodeWeaver against our seven comparison points.
Hypervisor
NodeWeaver supports KVM as the platform hypervisor. Version 12 of the platform represents a significant rewrite and update, adding critical enterprise-class features such as UEFI boot for cluster nodes (although secure boot is not supported) and UEFI for VM guests. We’ve previously highlighted the maturity of KVM, which has been a part of the Linux operating system for over 15 years. As such, we see no issues with using KVM in production environments.
The NodeWeaver solution currently only supports the x86-64 architecture with either Intel or AMD virtualisation extensions. We don’t believe there are any plans to support Arm or similar RISC-based solutions in the future.
There’s little more to say on the hypervisor choice, as within the market today there are only a handful of options available.
Platform Support
NodeWeaver is derived from open-source OpenNebula and designed to operate on a wide range of hardware configurations. The minimum hardware requirements are quite lightweight – a single CPU core on 64-bit x86, 8GB of system memory (2GB consumed by the hypervisor and management software), 120GB of storage (although 500GB is recommended) and gigabit ethernet networking (10GB is recommended). The software can run on a single node (without redundancy) or with high availability using two or more nodes. Nodes can be heterogeneous with any range of vendor hardware.
Flexibility outside of a strict hardware compatibility list is a valuable aspect for solutions that may be deployed in a range of computing environments and with potentially many generations of hardware. Of course, for simplicity and efficient support, we would always recommend using a self-imposed compatibility list or a pre-defined set of hardware choices.
Ecosystem
NodeWeaver is based on Alpine Linux, which is automatically pre-installed on physical server deployments using the default ISO option. The software can also be installed onto co-located equipment such as Equinix Metal. In this instance, the software is deployed onto a pre-defined Alpine Linux installation.
The NodeWeaver ecosystem is self-contained, with an integral GUI accessible from the single shared IP address across all nodes. Although the GUI provides access to a wide range of configuration options, most settings, such as networking and storage, are cluster-wide.
It is possible to administer NodeWeaver clusters using the OpenNebula CLI or through an integrated API. NodeWeaver release 12 is compatible with OpenNebula 6.2 APIs. Further support for infrastructure orchestrators including Terraform and Ansible is provided by OpenNebula compatibility and support.
While the integrated GUI enables the easy administration of individual NodeWeaver clusters, there is no higher-level capability for multi-cluster management. Of course, this feature could be implemented through third-party tools using the NodeWeaver/OpenNebula APIs. Note that there is a monitoring tool available called Edge.Insight, which runs as a separate application.
Commercials
As already highlighted, NodeWeaver is licensed by node, irrespective of the capability of that node. Prospective customers can try NodeWeaver for 30 days, after which new workloads can’t be started (although the cluster will continue to function). NodeWeaver Corporation doesn’t provide any online public information on pricing or licensing options (subscription or perpetual).
Deployment Model
We have discussed how NodeWeaver is targeted at edge and IoT solutions. Although the platform could be deployed in an enterprise data centre, specific features, such as the lack of external storage support, could be an issue for building large-scale virtual computing farms.
NodeWeaver can be deployed in bare-metal environments (Equinix is the example quoted in the documentation), and we see no reason why the software wouldn’t deploy in public clouds, although the use-case justification may be limited.
Features
With a long history based on OpenNebula, NodeWeaver is not short on features. The platform supports multi-tenancy with virtual networking, multiple data stores and quotas. Permissions are managed through users and groups for full tenancy control.
NodeWeaver offers a marketplace for pre-defined applications, while the Services feature enables the combination of multiple virtual instances into a single service definition. We haven’t looked into these features in depth yet, but the obvious use case is to build applications for remote deployment in edge locations.
Migration and Mobility
Virtual instances within NodeWeaver are based on the standard qcow2 format, so it would be possible to import and export VM images into and out of a cluster. However, we don’t believe the design philosophy of NodeWeaver is to build typical enterprise-class failover configurations because, at the edge, the cost and efficiency requirements are very different to mission-critical enterprise infrastructure.
The Architect’s View®
NodeWeaver is a mature and efficient hyper-converged infrastructure solution with a clear focus on edge and smaller computing environments. The licensing model is designed for requirements that need a unit cost pricing structure – one node, one licence.
We can see other scenarios where NodeWeaver could be a good fit for commercial enterprises. For example, non-production environments or small and mid-range businesses. However, the challenge for smaller IT organisations is perhaps the degree of configurability the NodeWeaver solution offers.
If we compare, for example, NodeWeaver with Scale Computing, both companies offer solutions for the edge. Scale Computing solutions have very few user-accessible configuration options, simplifying the administration overhead. The company has also introduced SaaS-based fleet management for large deployments.
There are also some operational quirks we experienced during the evaluation of NodeWeaver. VM cloning, for example, is based on the VM image, with the cloning process requiring a very specific set of steps. It wasn’t intuitive to achieve.
However, that said, NodeWeaver is a worthy solution for edge requirements and some small-scale data centre use cases. We’d like to see the option of a simplified GUI and perhaps some wizards to manage VM cloning.
We will keep the current configuration in the lab for a few more weeks and report back on some of the more advanced features, such as multi-tenancy and application libraries.
Copyright (c) 2007-2024 – Post #66f3 – Brookend Limited, first published on https://www.architecting.it/blog, do not reproduce without permission.

