Multi-Tenant LoadMaster - Product Overview
Multi-Tenant LoadMaster is Progress Kemp’s multi-tenancy product. It is a product where multiple independent instances of the LoadMaster and GEO LoadMaster can operate. These instances can be referred to as tenants, clients and Virtual Network Functions (VNFs). Each LoadMaster instance within the Multi-Tenant LoadMaster can be deployed, stopped, started and updated at will.
Licensing is done in the Multi-Tenant LoadMaster and is based on the maximum number of tenants that can be started. This means that the LoadMaster tenants do not need to be licensed individually. All of the LoadMaster tenants inherit a default license from the Multi-Tenant LoadMaster. The amount of tenants is limited based on the model purchased. Refer to the following page for details about the recommended and maximum number of tenants based on each model: Multi-Tenant LoadMaster Appliances.
Apart from the differences listed in the above paragraph, licensing the Multi-Tenant LoadMaster is the same as licensing a regular LoadMaster. For more information, and steps on how to license, refer to the Licensing, Feature Description.
The purpose of this document is to provide an overview of the Multi-Tenant LoadMaster which is Progress Kemp’s multi-tenancy product. For further information, such as instructional steps and a description of the Web User Interface (WUI) options, refer to the Multi-Tenant LoadMaster WUI, Configuration Guide.
This document is intended to be read by anyone who is interested in learning about the Multi-Tenant LoadMaster product.
Multi-Tenant LoadMaster has an Operating System (OS) running a hypervisor. The Multi-Tenant LoadMaster does not perform any load balancing – it handles requirements of the “client” Virtual Network Functions (VNFs). VNFs are the individual tenant LoadMasters that are deployed within the Multi-Tenant LoadMaster.
A package Virtual LoadMaster (VLM) template will be provided by Progress Kemp which contains the relevant firmware. This package can be installed on the Multi-Tenant LoadMaster. VLMs can then be started and configured from the Multi-Tenant LoadMaster.
When a VNF is no longer needed, it can be deleted.
Each VLM is independent, so its disk space is also independent. The current version of the LoadMaster can require up to 16 GB per VLM. A VLM requires at least 512MB of memory.
Some of the Multi-Tenant LoadMaster features are described in the sections below.
Ability to Create Virtual LoadMaster (VLM) Instances from Packages
A VNF package is LoadMaster or GEO LoadMaster image that can be used to create a LoadMaster VNF. Multiple packages can be installed on the Multi-Tenant LoadMaster. The Multi-Tenant LoadMaster will come with a pre-installed package which contains the latest LoadMaster firmware at that time. Other packages can be downloaded from the Progress Kemp website as needed. Each package can be a LoadMaster starting on different firmware (LTS, GA, and so on). From each package, multiple instances can be created.
VNF packages which were for pre-MT_7.1-30 firmware versions cannot be used to create VNFs on MT_7.1-30 or above. VNFs already created from these packages will continue to work. The latest VNF package can be downloaded from the Progress Kemp website.
When an instance is created from a VNF Package, the number of CPUs and amount of RAM can be configured.
There is a limit to the VNF size of the maximum number of cores of a single CPU on a multi-core platform. For example, on a dual CPU system with six cores per CPU, the maximum size that can be configured for a single VNF is six cores.
Application Templates Managed in the Multi-Tenant LoadMaster
Application templates make the setting up of Virtual Services easier by automatically configuring the parameters for a Virtual Service. Before a template can be used to configure a Virtual Service, it must be imported and installed on the Multi-Tenant LoadMaster or a tenant LoadMaster.
When templates are added to the Multi-Tenant LoadMaster, you can assign templates to specific VNFs as needed. The templates will then be available for use in the tenant LoadMaster when creating a new Virtual Service.
LoadMaster Manipulation in the Multi-Tenant LoadMaster
LoadMaster instances can be created, deployed, ran, stopped and destroyed in the Multi-Tenant LoadMaster.
It is possible to upgrade the Multi-Tenant LoadMaster firmware version. During the upgrade, a reboot is required which will interrupt all running virtual instances.
It is also possible to install a new VLM package template. This means that any time there is a new VLM release from Progress Kemp, the Multi-Tenant LoadMaster administrator can add a new VLM template. You can create a VNF instance from any of the installed VNF packages.
Existing tenants need to be upgraded in the usual manner, via the LoadMaster WUI.
It is possible to make backups of VNF instances at the Multi-Tenant LoadMaster-level. It is also possible to view the list of backups, download and delete backups that were previously taken. This function backs up the running LoadMaster configuration and does not actually take a backup of the running VM itself. You can restore a backup to a VNF if it is not running (a running VNF does not display the Restore option).
The Multi-Tenant LoadMaster creates one Open vSwitch (OVS) per physical/VLAN interface. This is the Virtual Switch software in the Multi-Tenant LoadMaster which allows multiple VLMs to share a common switch fabric. In addition, 10 host local networks are created. The tenant’s vNICs connect either to one of these switches or to one of the host local networks. Each tenant can have up to 10 vNICs named ETH0… 9. The network interfaces can only be configured when the tenant is not running.
LoadMaster bonding/VLAN tagging can be easily set up and configured using the WUI. Successful deployment requires that the pre-requisites have been satisfied. This guide is designed to introduce interface bonding and VLAN configuration on the LoadMaster. Bonding support is available with all network modules.
A list of prerequisites are below:
IEEE 802.1AX/IEEE 802.3ad/LACP
Enabling the Active-Backup mode generally does not require switch intervention and can be configured directly on the LoadMaster. Using the 802.3ad bonding mode will require configuring a link aggregation group on the switch in conjunction with the LoadMaster. Please read the switch documentation to establish the corresponding team/bond, common terms for link aggregation, which include; "Ethernet trunk", "NIC teaming", "port channel", "port teaming", "port trunking", "link bundling", "EtherChannel", "Multi-Link Trunking (MLT)", "NIC bonding", "Network Fault Tolerance (NFT)" and “LAG”.
When enabling VLAN trunking on the switch port make sure to configure the port to support the appropriate mode; General, Access, or Trunking. General descriptions are as follows (check the switch documentation for specifics):
General: the port belongs to VLANs, and each VLAN is user-defined as tagged or untagged (full 802.1Q mode)
Access: the port belongs to a single untagged VLAN
Trunk: the port belongs to VLANs in which all ports are tagged
There are a few key things to keep in mind when creating bonds/teams:
You can only bond interfaces higher than the parent, so if you choose to start with port 10 then you can only add ports 11 and greater
In order to add a link to a bonded interface, any IP addressing must first be removed from the link to be added
Bonding eth0 with eth1 can lead to serious issues and is not allowed to occur
Ensure that all bonded interfaces are configured for the same link speed, both on the switch and LoadMaster.
If bonding port 0, we recommend you move the web administrative interface and/or the remote SSH access to a different port temporarily until the bonding has been completely configured and is working.
Things to keep in mind:
VLANs can be added to physical interfaces or bonded interfaces
Multi-Tenancy, Feature Description
This document was last updated on 01 March 2023.