Overview

The following article aims to provide an architectural overview of SKUDONET software internals targeted to system administrators and software developers with an interest in knowing more about how SKUDONET ADC software works. All this information could be used as well to help with the configuration of production systems or troubleshooting purposes.

SKUDONET clarification

SKUDONET Open Source Load Balancer is a project started in 2010 by Emilio Campos, CEO of SKUDONET and former CTO of ZEVENET.

The project began with the name “Zen Load Balancer” and, since its inception, new software engineers joined the project, helping to create new properties and functionalities that have kept the project moving forward. Emphasize that at all times, the project that concerns us here has been designed, directed and managed by its founder Emilio Campos, who has always contributed the experience acquired working with other providers in the ADC market such as Radware, F5 or A10Networks, as well as developing similar properties, improving functionalities learned from other suppliers or developing community requests among many other management tasks.

After reading in some media and websites how secondary developers who have already abandoned the project call themselves “the head and core of the projects”, the founder Emilio Campos wants to show his satisfaction in knowing that an idea that emerged in 2010 has even served other people to start a new business, but he also wants to emphasize that the original idea of the project and the start of it are only attributable to him in its beginnings and to the magnificent team that continues working by his side at SKUDONET.

SKUDONET architecture

SKUDONET Open Source Load Balancer manages processes from both user and kernel space allowing it to gather the most performance but with the most flexibility as well to perform all the tasks delegated to the application delivery controller such as load balancing, security, and high availability.

The diagram below gives a global view of the different components that are composing the SKUDONET system internally. Additional pieces of less importance have been missed to offer a simpler and clearer view.

The following sections will describe the different pieces and how they are interconnected.

SKUDONET Load Balancer in User Space

The subsystems used in User Space are:

Web GUI: web graphic user interface used by users to manage the configuration and administration of the whole system, it is managed by an HTTPS webserver which consumes the SKUDONET API for all the actions done to the load balancer.

SKUDONET API: or SKUDONET Application program interface, designed following the REST and JSON interfaces, consumed through HTTPS, it is used by other different user interfaces from the user point of view such as the web GUI interface or ZCLI (SKUDONET command-line interface). This tool checks any action against the RBAC subsystem and if it is allowed the action is taken in the SKUDONET Appliance. The API can connect and manage any other userspace subsystem described in the diagram.

RBAC: Role-based access control is an access and control mechanism defined around users, groups, and roles. This module defines what actions a user is allowed to do with a high level of configuration between groups, users and roles. It is integrated into the web GUI interface that permits to load the web views based on the user role. Additionally, this subsystem is consumed through the API or any other tool that uses the API.

LSLB – HTTP(S): The LSLB module (Local Service Load Balancer) composed of HTTP(S) profile is executed in user space by a reverse proxy which can manage high throughput applications very efficiently. This subsystem is configured by the API and can be protected by the IPDS subsystem (using BlackLists, DoS rules, RBL and WAF rulesets).

GSLB: The GSLB module (Global Service Load Balancer) implemented with a GSLB profile instance is executed in user space by a DNS server process called Gdnsd that can work as an advanced DNS Nameserver with load balancing features. This subsystem is configured by the API and can be protected by the IPDS subsystem (using BlackLists, DoS and RBL).

Health Checks: This subsystem is configured by the API and used by all the load balancer modules (LSLB, GSLB, and DSLB) to check the health of the backends. Simple and advanced checks are executed against the backend and then if the check fails the backend for the given farm is marked as down and no more traffic is forwarded until the check works again against the backend. The Farm Guardian is responsible for these checks and it is designed with a high level of flexibility and configuration.

Configuration File System: This directory is used for configuration-saving purposes, any change in this directory will be replicated to the cluster if such service is enabled.

Nftlb: This userspace process is managed by the API subsystem and used for two main purposes: LSLB – L4XNAT management and configuration of the IPDS subsystem module.

SKUDONET Load Balancer in Kernel Space

The subsystems used in Kernel Space are:

Netfilter System LSLB L4xNAT: The Netfilter subsystem is used by SKUDONET for load balancing purposes. Netfilter rules are loaded in the kernel by this tool that just “rulerizes” the nftables commands. this process loads the load balancer rules in the kernel in an efficient way to manage the traffic packets as optimally as possible.

IPDS BlackLists: This subsystem is integrated into the Netfilter System and managed by Nftlb. It is composed of a group of rules configured before the load balancer rules to drop connections for the given origin IPs. Internally it creates a set of rules ordered by category, country, types of attacker, etc and is updated daily.

IPDS RBL: Analogously to the previous one, this subsystem is integrated into Netfilter too and managed by Nftlb. The origin IP is captured before the connection establishment and the client IP is validated against an external DNS service. If the IP is resolved then the IP is marked as malicious and the connection will be dropped.

IPDS DoS: The same configuration system as the two previous modules, integrated into Netfilter and managed by Nftlb. It is a set of rules configured before the load balance rules that check if the packets are part of a Denial of Service attack. Some rules are applied to the packet flow to intercept the attack before it is done.

Connection tracking system: This system is used by the Netfilter subsystem for connection management purposes, network translation and the statistics module, as well as the health check subsystem to force connection actions at the moment an issue is detected in the backend. The connection tracking system is also used by the Clustering service to forward the connection status to the second node of the cluster, in case a cluster master node fails then the second node can manage the traffic in the same connection status as the previous master.

Routing System and DSLB: These subsystems are managed by the API and configured in the Kernel space. The routing subsystem is built with iproute2 which allows us to manage multiple routing tables to avoid maintaining a complex ruleset for static routing, additionally, thanks to iproute2 the DSLB (Datalink Service Load Balancer) module is created to provide load balancing of uplinks with several gateways.

At the moment of writing this article, SKUDONET 6 is in production, so those subsystems could evolve in future versions to offer better performance and more features.