VELOS: A Chassis Reimagined

F5 Networks launched their first chassis system, the VIPRION family with the release of the 4400 series in late 2008. This was the first time that a customer could buy an Application Delivery Controller (ADC) that could scale with their needs, with the ability to add additional blades to the chassis to grow the device's capabilities as needed. With the introduction of virtual clustered multi-processing (vCMP), the monolithic chassis was made more flexible, allowing customers to carve up the resources amongst much smaller "virtual" BIG-IPs, akin to how VMware ESXi allows customers to better utilize their hardware investment. 

Since 2008, the VIPRION 2200, 2400, 4480 and 4800 chassis have been released, along with a plethora of different blades to meet the ever-changing needs of customers, until today, with the above chassis still available and with current blades can reach up to 1.28Tbps of throughput on a single chassis. The addition of vCMP allowed the VIPRION to scale horizontally in addition to vertically.

A need for change

With this level of scalability and flexibility, why change the platform? There are multiple reasons that the VIPRION platform needed to be looked at and reevaluated, but for the sake of brevity we'll briefly address three reasons.

vCMP

F5's vCMP  allows the virtualization of F5 hardware into multiple virtual BIG-IPs, not dissimilar to how compute and storage has been done in the data center space. There were limitations on how CPU and memory could be allocated though. When creating a guest on a vCMP system, memory was a fixed amount per core. Additionally, vCMP guests could only have an even number of cores per guest, with the exception being a single-core guest. This could lead to orphan cores or memory on a blade. If a use case requires more memory for the guest, but not more cores, vCMP will require more cores to be added to add the required memory. 

Hardware

VIPRION blades such as the b2150 and b2250 were released in 2013 and 2014 respectively. Some of the technology on these blades is obsolete. As an example, the b2150 and b2250 blades use Cavium chips on them for SSL/TLS offloading, a great and oft-used feature, but these chips cannot handle modern SSL/TLS certificates such as ECC and PFS, which leaves this to the main CPU to handle. The main CPU is a 10-core Intel Xeon processor that was current in 2013 — this could put undue burden and stress on the CPU. 

Combined control and data plane

As alluded to above, VIPRION has the control and the data plane combined. This means the same processors and memory being used to deliver the traffic is also used to manage the devices. This means that when utilizing features such as vCMP, you lose up to 20 percent of the resources to the overhead of managing the hypervisor. 

The change

The successor to VIPRION is the VELOS platform. It is appropriate to call VELOS a platform, because of the completely redesigned architecture. While it is still a bladed chassis like the VIPRION platform, that is where the similarities seemingly end.

Before addressing how the VELOS platform is different from the current VIPRION platform, I must caution that some of this is likely to change. VELOS is still in EA (early access) and as such, some of this could change before full release, which is scheduled during WWT's Q3. We've had the VELOS platform in the ATC since September 2020 and have been testing it and working with F5's product development and product management teams.

Hardware

The first thing that has changed is density. The cx410 chassis takes both half and quarter blades. Currently only the quarter blades, the bx110, is out. The chassis can handle 8 quarter blades or 4 half blades. The bx110 is no slouch though, with 1 14-core Intel Xeon processor (28 hyper threads) and 128GB of RAM. These blades also have SSL/TLS offloading that can offload modern ciphers, such as PFS certificates, which the VIPRION had to handle in the main CPU.

Control and data plane

Another major change between these platforms is the splitting of the platform's control and data planes. The VELOS platform has redundant system controllers onboard. The system controllers are components of the chassis that provide a unified point for external management and connectivity to the platform and applications running in the chassis. The chassis contains a redundant pair of system controllers that provides a high bandwidth interconnect between blades and high availability. The system controllers also provide REST APIs, a system controller CLI and a webUI.

Tenants

Finally, there are the tenants, which are like a vCMP guest but with greater flexibility and configurability. There are a few more concepts here such as partitions, but those are for a follow-up post. A tenant is a guest system running software in a chassis partition (for example, a Classic BIG-IP system). You can run several tenants in the same chassis partition. The maximum number of lightweight tenants that can be created in a blade is 22. Each blade has 128GB memory, of which 95GB is reserved for tenants. Each lightweight tenant requires a minimum of one vCPU and 4096 MB minimum memory.

At launch, tenants are limited to traditional BIG-IP that we are all familiar with, but there is the potential for other tenant types to further enhance the flexibility of the platform.

Conclusion

If we are to sum up VELOS as succinctly as possible, VELOS as a platform is a self-contained Kubernetes-based OpenShift cluster providing a highly scalable, flexible and automatable application delivery platform. 

From just these three points above, it is apparent that VELOS is a wholly different platform than VIPRION. It addresses the problems inherent in the combined control and data plane, vCMP inflexibly and the limitations of the current platform's hardware.