F5 R-Series, F5 Velos and The Future of the ADC World
F5 has recently released new hardware appliances that are called rSeries (F5OS-A) and chassis with the name of Velos (F5OS-C), but what does that mean and why is it important for everyone that works with ADC devices?
To answer this question, we have to look at the current ADC systems that are on the market and their limitations. The current ADC systems are based on monolithic software, so each time a bug is encountered in one of the features, usually an upgrade to a new software release is needed as it is hard to fix only the affected component in a monolithic software structure. Moreover, the web applications or all applications in general are moving to containers and Kubernetes deployments and this so-called "Microservices" approach. As the ADC systems need to integrate with the newer Microservice based applications it becomes increasingly hard, because the old ADC systems were designed for load balancing and protecting applications that at the maximum have 3 layers that are web interface frontend, application backend and the SQL database. This has created the need for a new approach in designing and building ADC systems.
Monolithic architecture vs Microsevices Architecture
This is where F5OS comes into play and in the future, BIG-IP NEXT. The new F5OS software is vastly different than the old F5 TMOS and vCMP, as it uses Kubernetes and even Openshift for the chassis as to utilize containers for realizing the different functions and features for the F5OS, and making use of automatic orchestration that Kubernetes provides for developing software.
Special features that F5OS-A/F5OS-C brings:
The F5OS utilizes RESTCONF for API and by following this standard the API management and automation of the F5 hardware devices is much simpler. As RESTCONF is used by many IT Vendors like Cisco this makes the automation of the F5OS much simpler as there is no need to learn a new structure API. Anything that is done by the GUI or CLI, can be done by API as even the F5OS GUI is doing API calls that can be reviewed in the background browser developer tools. For more about the F5OS API, you can review the F5 Devcentral Code article that I previously wrote as an MVP Member in F5: F5 Velos/rSeries/F5OS code for automating config b... - DevCentral
The F5OS software allows tcpdumps for tenant traffic to be done even from the Velos partition or rSeries CLI/GUI interface with a new tcpdump utility. This utility is accessed from the F5OS shell and not the Linux bash shell with the command and here is an example command: "system diagnostics tcpdump bpf "src host 10.10.1.1 and dst port 443".
The F5OS has new diagnostic commands that replace the old EUD hardware test and this allows a hardware issue to be captured much faster than with EUD and most of all it can done without traffic interruption. An example command "show system health components" as the output of this command is visualized in the website F5 ihealth when a qkview tech support file is uploaded.
You can upgrade the F5OS services or base-os separately thanks to the fact that the F5OS software is developed following the microservices approach that I mentioned earlier. This will allow in the future easier implementation of patch upgrades to resolve software bugs without doing a full system upgrade.
F5OS log files can directly be exported from the GUI thanks to the new utility file that F5OS has and they can even be sent to an HTTPS server. The utility file can also be managed with the RESTCONF API like anything in F5OS as the system is designed to be API first.
F5OS GUI interface
F5OS CLI
F5OS RESTONF API
Some special features just for F5OS-A/r-Series:
The F5OS-A software will make a better use of Field Programmable Gate Arrays (FPGA’s) allowing for better virtual-wire deployments, where two interfaces/trunks are linked together on the physical level of the OSI Model. The FPGA will allow you to select portgroup mode of the physical interfaces, where you can have an interface that is 40Gb/100Gb or you can have 4 interfaces with lower speeds that are 25Gb/10Gb.
F5OS-A basic overview
Some special features just for F5OS-C/Velos.
The Velos chassis uses an active backplane compared to the VIPRION chassis and this allows for segregating the blades in different partitions and then creating the F5 tenants inside the partitions.
For Velos there are 2 controllers that are in active/standby mode and this allows for better fault tolerance. Also, when performing software upgrades, one controller can take the role of active while the other controller is being upgraded and after that the controllers will automatically switch their roles as the upgraded controller will become active, so that the other controller can safely be upgraded - this is called a rolling upgrade. A rolling upgrade installs the new F5OS version on one system controller or blade in a chassis partition at a time, without an interruption to system controller availability. Keep in mind that the active controller for the chassis and the active controller inside a partition could be different.
F5OS-C basic overview
At the moment there is not so much info for BIG-IP NEXT but we can safely assume that all of the features and design software practices seen in F5OS will be relevant for BIG-IP NEXT and from what is shown in the first picture, there should be a way to upgrade the software of the different F5 modules like AFM/APM/AWAF/LTM/GTM/PEM separately.
F5 has a migration tool for migrating from old F5 devices to F5OS called Journeys, so I suggest that you check it out:
F5 has released new guides for F5OS chassis or appliance that are a great source of information for anyone willing to know more and I strongly recommend to review them:
Planning for rSeries Guide (f5.com)
Planning for VELOS Guide (f5.com)
Author: Nikolay Dimitrov