VELOS: Multi-Tenancy Like a Boss

In the previous article on the upcoming F5 VELOS platform, we discussed three pivotal reasons for the changes between the long-lived VIPRION platform and the new VELOS platform. The goal of this next series of articles is to go into further detail on each of these three reasons allowing a better understanding of why these changes are needed and how they can affect operations in your organization. 

In this 1st of 3 articles covering these platform design changes, we will discuss virtualization/multi-tenancy and the change from vCMP to tenants in VELOS and how this affects the platform, and how VELOS will be thought of and used. 

F5's legacy architecture

vCMP technology is how F5 virtualized their hardware platforms in the most current and previous generations, included the powerful VIPRION chassis platform. This was accomplished using highly modified KVM that allowed F5 hardware to host virtual instances of the TMOS software. This had the added advantage of allowing those guests full access to the specialized hardware on the platform, such as FPGAs for SSL decryption and compression. 

F5's modern architecture

VELOS, unlike the previous platforms, was built from the ground up for containerization, virtualization, and multi-tenancy. VELOS does this not with the hypervisor construct of yore, but with the new F5OS platform, a true microservices layer utilizing the Kubernetes framework for the management of the platform. As mentioned in the last article, VELOS is a self-contained OpenShift cluster, but F5OS provides a layer of abstraction, simplifying management of the VELOS platform. 

As it stands today, F5OS is utilizing KubeVirt technology to run classic BIG-IP instances as virtual machines on top of the microservices architecture. These instances are referred to as tenants. This allows for ease of migration from legacy BIG-IP instances and increased deployment speed. Additionally, this architecture will host the future of BIG-IP, where the application services will no longer run in TMOS, but are truly containerized, running in the native F5OS environment. These will be able to run side-by-side with classic BIG-IP, giving the VELOS platform an easy migration path.

Chassis partitioning

VELOS' F5OS chassis partitioning provides adds an additional layer of isolation. This allows one or more blades to be isolated and assigned to partitions, each with their own isolated networking, user interfaces, and user authentication. For example, a VELOS could have a regulated and unregulated partition, where BIGIPs that must meet specific regulatory requirements are housed with restricted administrative access, while the unregulated partition for internal application has different administration, networking and policy. 

This creates three major administration roles within the VELOS platform: Chassis Administrator, Chassis Partition Administrator and Tenant Administrator. The Chassis Administrator has full access to the chassis' out-of-band management of the two system controllers and can configure partitions and user rights to the partitions. 

The Chassis Partition Administrator has full administrative rights to a particular partition. This means they configure the networking for the partition they have rights to, such as interfaces, LAGs, and VLANs. The Chassis Partition Administrator also will deploy tenants and assign resources to the tenants, including the software. 

Finally, the Tenant Administrator is the administrator of the tenants themselves and this is handled by the tenant. Currently, with the tenant being the classic BIGIP, the administration and users for that tenant are handled the same way they are on BIGIP currently. This role has no rights or privileges whatsoever on the lower, F5OS level of the chassis.