Networking

Private cloud networking is fraught with technical complexity and is often where most private cloud projects fall over. This is true both at the physical and virtual layers.

The main reasons for this that we've seen tend to be:

• Caveman orchestration: While modern switches are essentially just servers with dedicated networking ASICs, the industry has somehow made it this far while being almost immune to modern deployment concepts and automation, leading to manageability nightmares at scale.
• Dearth of smart management software: While many of the underlying protocols for packet inspection, L2 discovery and analysis tooling are present, the user-level software to wrap and weaponize these protocols to make network admin or smart hands' lives easier just does not exist. Where's the GitHub of LLDP?
• Vendor obscurity: Often, simple networking concepts are made far less manageable thanks to vendors developing their own non-standard implementations, or in many cases going out of their way to obstruct interoperability. See:
• Race to the bottom: The success of ODMs (Original Design Manufacturers) and faceless hardware vendors in penetrating a previously impenetrable global market has led to ethernet infrastructure which is far less dependable, even with core functionality.

To add to this, minor mistakes in both physical and virtual networking either at design or implementation can have a fatal impact on a private cloud deployment. Full system failure is bad, but partial system failure can be even worse.

To address this, we have a few goals for our approach to networking:

• Keep it as simple as possible: Some complexity cannot be avoided, but adding complex networking features without justification is criminal. In addition, leveraging features specific to single vendors is an absolute no-no.
• Build networking resilience on multiple levels: If we have resilience on a number of levels when we design our architecture, we can survive human and systematic error.
• Standardize network architecture at the node level: Let's avoid snowflake designs for any special nodes - there should be a straightforward standard operating procedure for every server.
• Do the heavy-lifting in the node bring-up: Rather than relying on magic or special switch configuration, we can rely on the nodes and L2 protocols to automatically detect and decide on their own configuration, and keep switch configuration as homogeneous as possible.

Physical

Within the confines of a single rack, the HyperCloud networking configuration will almost always look the same. It will consist of multiple interconnect nodes - these encompass both ethernet networking and out-of-band networks. The interconnect nodes use redundant links between each other and the compute and storage nodes.

Once the architecture begins to span multiple racks, the network configuration will be a full mesh architecture for maximum resilience. Full mesh is sustainable across a number of racks - once deployment scale exceeds a certain critical mass, it moves to a leaf-spine architecture.

To make physical network implementation as easy as possible and reduce the risk of mistakes, network ports and cabling are color-coded. Detailed IKEA-style manuals are provided for remote hands teams such as DC Ops and Break-fix. In some cases, we may supplement deployment with our own professional services, or services from one of our channel partners, to assist with physical networking implementation.

Virtual

The virtual networking layer in HyperCloud exists to bridge and abstract the physical layer to tenanted guests within the cloud. This enables the creation of:

• Virtual networks
• Virtual network templates
• Virtual routers via the gateway appliance

Virtual networks can be created spanning compute nodes to manage the underlying networking of VMs and containers within HyperCloud.

These virtual networks consist of an address space and a guest configuration which is automatically applied to guests on provisioning. Provisioned address spaces can consist of IPv4, IPv6 (SLAAC/no-SLAAC), dual stack, or ethernet-only. For each of these address spaces, MACs can either be a specified range, or auto-generated.

Similar to virtual networks, virtual network templates can be created by operators to provide tenants with flexible network templates which also restrict user networking to within defined parameters. This includes network-level quality of service with bandwidth throttling, and spoofing filters.

Security Groups

Security groups are configurable rules for Inbound and Outbound traffic for TCP, UDP, ICMP and IPSec. They can be applied to virtual networks and virtual network templates, or individually against VMs or containers when either is configured with a virtual network.